stringtranslate.com

Software de código abierto

Una captura de pantalla de Manjaro ejecutando el entorno de escritorio Cinnamon , Firefox accediendo a Wikipedia que utiliza MediaWiki , LibreOffice Writer , Vim , GNOME Calculator , VLC y el administrador de archivos Nemo , todos los cuales son software de código abierto.

El software de código abierto ( OSS ) es un software informático que se publica bajo una licencia en la que el titular de los derechos de autor otorga a los usuarios los derechos de uso, estudio, modificación y distribución del software y su código fuente a cualquier persona y para cualquier propósito. [1] [2] El software de código abierto puede desarrollarse de manera colaborativa y pública. El software de código abierto es un ejemplo destacado de colaboración abierta , lo que significa que cualquier usuario capaz puede participar en línea en el desarrollo, lo que hace que el número de posibles contribuyentes sea indefinido. La capacidad de examinar el código facilita la confianza pública en el software. [3]

El desarrollo de software de código abierto puede aportar perspectivas diversas más allá de las de una sola empresa. Se estima que en 2024 el valor del software de código abierto para las empresas será de 8,8 billones de dólares, ya que las empresas tendrían que gastar 3,5 veces más de lo que gastan actualmente sin el uso de software de código abierto. [4]

El código fuente abierto se puede utilizar para estudiar y permite a los usuarios finales capaces adaptar el software a sus necesidades personales de una manera similar a como lo permiten los scripts de usuario y las hojas de estilo personalizadas para los sitios web, y eventualmente publicar la modificación como una bifurcación para usuarios con preferencias similares y enviar directamente posibles mejoras como solicitudes de extracción .

Definiciones

El logotipo de la Iniciativa de Código Abierto

La definición de la Iniciativa de Código Abierto (OSI) es reconocida por varios gobiernos a nivel internacional [5] como la definición estándar o de facto . OSI utiliza la Definición de Código Abierto para determinar si considera que una licencia de software es de código abierto. La definición se basó en las Pautas de Software Libre de Debian , escritas y adaptadas principalmente por Perens . [6] [7] [8] Perens no basó su escrito en las "cuatro libertades" de la Free Software Foundation (FSF), que solo estuvieron ampliamente disponibles más tarde. [9]

Según la definición de Perens, el código abierto es una licencia de software amplia que pone el código fuente a disposición del público en general con restricciones laxas o inexistentes sobre el uso y la modificación del código. Una "característica" explícita del código abierto es que impone muy pocas restricciones sobre el uso o la distribución por parte de cualquier organización o usuario, con el fin de permitir la rápida evolución del software. [10]

Según Feller et al. (2005), los términos "software libre" y "software de código abierto" deberían aplicarse a cualquier "producto de software distribuido bajo términos que permitan a los usuarios" utilizar, modificar y redistribuir el software "de cualquier manera que consideren adecuada, sin exigirles que paguen a los autores del software una regalía o tarifa por participar en las actividades enumeradas". [11]

A pesar de haberlo aceptado inicialmente, [12] Richard Stallman de la FSF ahora se opone rotundamente a que el término "código abierto" se aplique a lo que ellos denominan "software libre". Aunque está de acuerdo en que los dos términos describen "casi la misma categoría de software", Stallman considera que equiparar los términos es incorrecto y engañoso. [13] Stallman también se opone al pragmatismo profesado por la Open Source Initiative , ya que teme que los ideales del software libre de libertad y comunidad se vean amenazados al comprometer los estándares idealistas de la FSF para la libertad del software. [14] La FSF considera que el software libre es un subconjunto del software de código abierto, y Richard Stallman explicó que el software DRM , por ejemplo, puede desarrollarse como código abierto, a pesar de que no da libertad a sus usuarios (los restringe), y por lo tanto no califica como software libre. [13]

Desarrollo de software de código abierto

Modelo de desarrollo

En su ensayo de 1997 The Cathedral and the Bazaar (La catedral y el bazar) , el influyente colaborador de código abierto Eric S. Raymond sugiere un modelo para desarrollar OSS conocido como el modelo bazar . [15] Raymond compara el desarrollo de software mediante metodologías tradicionales con la construcción de una catedral, con un trabajo aislado y cuidadoso por parte de individuos o pequeños grupos. [15] Sugiere que todo el software debería desarrollarse utilizando el estilo bazar, con diferentes agendas y enfoques. [15]

En el modelo tradicional de desarrollo, al que llamó modelo catedral , el desarrollo se lleva a cabo de manera centralizada. [15] Los roles están claramente definidos. [15] Los roles incluyen personas dedicadas al diseño (los arquitectos), personas responsables de gestionar el proyecto y personas responsables de la implementación. [15] La ingeniería de software tradicional sigue el modelo catedral. [15]

Sin embargo, el modelo de bazar es diferente. [15] En este modelo, los roles no están claramente definidos. [15] Algunas características propuestas del software desarrollado utilizando el modelo de bazar deberían exhibir los siguientes patrones: [16]

Los usuarios deben ser tratados como co-desarrolladores: Los usuarios son tratados como co-desarrolladores y por lo tanto deben tener acceso al código fuente del software. [16] Además, se anima a los usuarios a enviar adiciones al software, correcciones de código para el software, informes de errores , documentación, etc. Tener más co-desarrolladores aumenta la velocidad a la que evoluciona el software. [16] La ley de Linus establece que dada la cantidad suficiente de ojos, todos los errores son superficiales. [16] Esto significa que si muchos usuarios ven el código fuente, eventualmente encontrarán todos los errores y sugerirán cómo solucionarlos. [16] Algunos usuarios tienen habilidades de programación avanzadas y, además, la máquina de cada usuario proporciona un entorno de prueba adicional. [16] Este nuevo entorno de prueba ofrece la capacidad de encontrar y solucionar un nuevo error. [16]

Lanzamientos tempranos : la primera versión del software debe lanzarse lo antes posible para aumentar las posibilidades de encontrar codesarrolladores de manera temprana. [16]

Integración frecuente: los cambios de código deben integrarse (fusionarse en una base de código compartida) tan a menudo como sea posible para evitar la sobrecarga de corregir una gran cantidad de errores al final del ciclo de vida del proyecto. [16] [17] Algunos proyectos de código abierto tienen compilaciones nocturnas donde la integración se realiza automáticamente . [16]

Varias versiones: Debería haber al menos dos versiones del software. [16] Debería haber una versión con más errores y más funciones, y una versión más estable con menos funciones. [16] La versión con errores (también llamada versión de desarrollo) es para los usuarios que desean utilizar de inmediato las últimas funciones y están dispuestos a aceptar el riesgo de utilizar código que aún no se ha probado exhaustivamente. [16] Los usuarios pueden actuar como co-desarrolladores, informando de los errores y proporcionando correcciones de errores. [16] [18]

Alta modularización: La estructura general del software debe ser modular permitiendo el desarrollo paralelo en componentes independientes. [16]

Estructura de toma de decisiones dinámica: existe la necesidad de una estructura de toma de decisiones, ya sea formal o informal, que tome decisiones estratégicas en función de los requisitos cambiantes de los usuarios y otros factores. [16] Compárese con la programación extrema . [16]

El proceso de desarrollo de código abierto comienza con una elicitación de requisitos donde los desarrolladores consideran si deben agregar nuevas características o si es necesario corregir un error en su proyecto. [18] Esto se establece comunicándose con la comunidad de OSS a través de vías como informes y seguimiento de errores o listas de correo y páginas de proyectos. [18] Luego, los desarrolladores de OSS seleccionan o se les asigna una tarea e identifican una solución. Debido a que a menudo hay muchas rutas posibles diferentes para las soluciones en OSS, la mejor solución debe elegirse con una cuidadosa consideración y, a veces, incluso con la retroalimentación de los pares . [18] Luego, el desarrollador comienza a desarrollar y confirmar el código. [18] Luego, el código es probado y revisado por pares. [18] Los desarrolladores pueden editar y desarrollar su código a través de la retroalimentación de la integración continua . [18] Una vez que el liderazgo y la comunidad están satisfechos con todo el proyecto, se puede lanzar parcialmente y se pueden documentar las instrucciones del usuario. [18] Si el proyecto está listo para ser lanzado, se congela y solo se producen correcciones de errores graves o reparaciones de seguridad. [18] Finalmente, el proyecto se lanzó en su totalidad y solo se modificaron algunas correcciones de errores menores. [18]

Ventajas

La implementación de un estándar en código abierto puede aumentar la adopción de ese estándar. [19] Esto crea lealtad entre los desarrolladores, ya que se sienten empoderados y tienen un sentido de propiedad del producto final. [20]

Además, se necesitan menores costos de marketing y servicios logísticos para el OSS. [21] El OSS puede ser una herramienta para promover la imagen de una empresa, incluidos sus productos comerciales. [22] El enfoque de desarrollo del OSS ha ayudado a producir software confiable y de alta calidad de manera rápida y económica. [21]

El desarrollo de código abierto ofrece el potencial de acelerar la innovación y crear valor social. [23] En Francia, por ejemplo, una política que incentivaba al gobierno a favorecer el software libre de código abierto aumentó a casi 600.000 las contribuciones de OSS por año, generando valor social al aumentar la cantidad y la calidad del software de código abierto. [23] Esta política también condujo a un aumento estimado de hasta el 18% de las nuevas empresas tecnológicas y un aumento del 14% en el número de personas empleadas en el sector de TI. [23]

El código abierto puede ser muy confiable cuando cuenta con miles de programadores independientes que prueban y corrigen errores del software. [16] El código abierto no depende de la empresa o el autor que lo creó originalmente. [24] Incluso si la empresa fracasa, el código continúa existiendo y siendo desarrollado por sus usuarios. [24]

El OSS es flexible porque los sistemas modulares permiten a los programadores construir interfaces personalizadas o añadirles nuevas capacidades y es innovador porque los programas de código abierto son el producto de la colaboración entre un gran número de programadores diferentes. [16] La mezcla de perspectivas divergentes, objetivos corporativos y metas personales acelera la innovación. [25]

Además, el software libre puede desarrollarse de acuerdo con requisitos puramente técnicos. [26] No requiere pensar en la presión comercial que a menudo degrada la calidad del software. [26] Las presiones comerciales hacen que los desarrolladores de software tradicionales presten más atención a los requisitos de los clientes que a los requisitos de seguridad, ya que dichas características son algo invisibles para el cliente. [26]

Herramientas de desarrollo

En el desarrollo de software de código abierto, se utilizan herramientas para respaldar el desarrollo del producto y el proceso de desarrollo en sí. [18]

Los sistemas de control de versiones como el sistema de control de versiones centralizado (CVCS) y el sistema de control de versiones distribuido (DVCS) son ejemplos de herramientas, a menudo de código abierto, que ayudan a gestionar los archivos de código fuente y los cambios en esos archivos para un proyecto de software con el fin de fomentar la colaboración. [27] Los CVCS están centralizados con un repositorio central, mientras que los DVCS están descentralizados y tienen un repositorio local para cada usuario. [27] El sistema de versiones concurrentes (CVS) y más tarde Subversion (SVN) y Git son ejemplos de CVCS. [27] Los repositorios se alojan y publican en instalaciones de alojamiento de código fuente como GitHub . [27]

Los proyectos de código abierto utilizan utilidades como los rastreadores de problemas para organizar el desarrollo de software de código abierto. Los rastreadores de errores más utilizados son Bugzilla y Redmine . [18]

Herramientas como listas de correo e IRC proporcionan medios de coordinación y discusión de errores entre desarrolladores. [18] Las páginas web del proyecto, las páginas wiki, las listas de hojas de ruta y los grupos de noticias permiten la distribución de información del proyecto enfocada en los usuarios finales. [18]

Oportunidades de participación

Contribuyendo

Los roles básicos de los participantes de OSS pueden clasificarse en varias categorías, comenzando con el liderazgo en el centro del proyecto que tiene control sobre su ejecución. [28] A continuación están los colaboradores principales con mucha experiencia y autoridad en el proyecto que pueden guiar a los demás colaboradores. [28] Los colaboradores no principales tienen menos experiencia y autoridad, pero contribuyen regularmente y son vitales para el desarrollo del proyecto. [28] Los nuevos colaboradores son los menos experimentados pero con tutoría y orientación pueden convertirse en colaboradores regulares. [28]

Algunas de las posibles formas de contribuir al software de código abierto incluyen funciones como programación , diseño y prueba de interfaz de usuario, diseño web , clasificación de errores , diseño y prueba de accesibilidad, diseño de UX , prueba de código y revisión y prueba de seguridad . [28] Sin embargo, existen varias formas de contribuir a proyectos de OSS incluso sin habilidades de codificación. [28] Por ejemplo, algunas formas menos técnicas de participar son la redacción y edición de documentación , la traducción , la gestión de proyectos , la organización y coordinación de eventos, el marketing, la gestión de lanzamientos, la gestión de la comunidad y las relaciones públicas y la divulgación. [28]

La financiación es otra forma estupenda que tienen las personas y las organizaciones de contribuir a los proyectos de código abierto. Grupos como Open Collective ofrecen a las personas un medio para contribuir mensualmente a sus proyectos favoritos. [29] Organizaciones como Sovereign Tech Fund pueden contribuir con millones de dólares para apoyar las herramientas que utiliza el gobierno alemán . [30] La National Science Foundation estableció un programa Pathways to Enable Open-Source Ecosystems (POSE) para apoyar la innovación de código abierto. [31]

Participación de la industria

La adopción de software de código abierto por parte de la industria está aumentando con el tiempo. [32] El OSS es popular en varias industrias, como las telecomunicaciones , la aeroespacial , la atención médica y los medios de comunicación y entretenimiento debido a los beneficios que proporciona. [33] La adopción de OSS es más probable en organizaciones más grandes y depende del uso de TI de la empresa, las eficiencias operativas y la productividad de los empleados. [32]

Es probable que las industrias utilicen OSS debido a la funcionalidad de back-office, soporte de ventas, investigación y desarrollo, características del software, implementación rápida, portabilidad entre plataformas y evitación de la gestión de licencias comerciales. [32] Además, el menor costo del hardware y la propiedad también son beneficios importantes. [32]

Organizaciones destacadas

Existen organizaciones que contribuyen al desarrollo y expansión de movimientos de software libre y de código abierto en todo el mundo. [28] Estas organizaciones se dedican a objetivos como la enseñanza y la difusión de la tecnología. [28] Como lo enumera un ex vicepresidente de la Open Source Initiative , algunas organizaciones estadounidenses incluyen la Free Software Foundation , Software Freedom Conservancy , la Open Source Initiative y Software in the Public Interest . [28] Dentro de Europa, algunas organizaciones notables son la Free Software Foundation Europe , los proyectos de código abierto EU (OSP) y OpenForum Europe (OFE). [28] Una organización australiana es Linux Australia, mientras que Asia tiene Open source Asia y FOSSAsia. [28] Free and open source software for Africa (FOSSFA) y OpenAfrica son organizaciones africanas y Asia Central y del Sur tiene organizaciones como FLISOL y GRUP de usuarios de software libre Perú. [28] Fuera de estas, existen muchas más organizaciones dedicadas al avance del software de código abierto. [28]

Cuestiones jurídicas y económicas

Licencias

Los productos FOSS generalmente se licencian bajo dos tipos de licencias: licencias permisivas y licencias copyleft . [34] Ambos tipos de licencias son diferentes a las licencias propietarias en que pueden permitir que más usuarios accedan al software y permiten la creación de trabajos derivados según lo especificado por los términos de la licencia específica, ya que cada licencia tiene sus propias reglas. [34] Las licencias permisivas permiten a los destinatarios del software implementar los derechos de autor del autor sin tener que usar la misma licencia para la distribución. [34] Ejemplos de este tipo de licencia incluyen las licencias BSD , MIT y Apache . [34] Las licencias copyleft son diferentes en que requieren que los destinatarios usen la misma licencia para al menos algunas partes de la distribución de sus trabajos. [34] Las licencias copyleft fuertes requieren que todos los trabajos derivados usen la misma licencia mientras que las licencias copyleft débiles requieren el uso de la misma licencia solo bajo ciertas condiciones. [34] Ejemplos de este tipo de licencia incluyen la familia de licencias GNU y las licencias MPL y EPL . [34] Las similitudes entre estas dos categorías de licencias incluyen que proporcionan una amplia concesión de derechos de autor, requieren que los destinatarios conserven los avisos de derechos de autor y que se proporcione una copia de la licencia a los destinatarios junto con el código. [34]

Un precedente legal importante para el software de código abierto se creó en 2008, cuando el caso Jacobson v Katzer hizo cumplir los términos de la licencia Artistic , incluida la atribución y la identificación de modificaciones. [34] El fallo de este caso consolidó la aplicación de la ley de derechos de autor cuando no se cumplieron las condiciones de la licencia. [34] Debido a la similitud de la licencia Artistic con otras licencias de software de código abierto, el fallo creó un precedente que se aplicó ampliamente. [34]

Algunos ejemplos de licencias de software libre / licencias de código abierto incluyen las licencias Apache , las licencias BSD , las licencias públicas generales de GNU , la licencia pública general reducida de GNU , la licencia MIT , la licencia pública Eclipse y la licencia pública de Mozilla . [34]

Cuestiones jurídicas

Existen varias áreas grises dentro de la regulación del software que tienen un gran impacto en el software de código abierto, como por ejemplo si el software es un bien o un servicio, qué se puede considerar una modificación, la gobernanza mediante contrato vs. licencia, la propiedad y el derecho de uso. [34] Si bien ha habido avances en estas cuestiones, a menudo conducen a aún más preguntas. [34] La existencia de estas incertidumbres en la regulación tiene un impacto negativo en las industrias involucradas en tecnologías en su conjunto. [34]

Dentro de la historia legal del software en su conjunto, hubo mucho debate sobre si protegerlo como propiedad intelectual bajo la ley de patentes , la ley de derechos de autor o establecer una regulación única. [34] En última instancia, la ley de derechos de autor se convirtió en el estándar y los programas de computadora se consideraron una forma de trabajo literario, con algunos ajustes de regulación única. [34]

El software generalmente se considera código fuente y código objeto , y ambos son protegibles, aunque hay variedad legal en esta definición. [34] Algunas jurisdicciones intentan expandir o reducir esta conceptualización para sus propios fines. [34] Por ejemplo, el Tribunal de Justicia Europeo define un programa de computadora como no incluyendo la funcionalidad de un programa, el lenguaje de programación o el formato de los archivos de datos. [34] Al limitar las protecciones de los diferentes aspectos del software, la ley favorece un enfoque de código abierto para el uso del software. [34] Estados Unidos especialmente tiene un enfoque abierto para el software, y la mayoría de las licencias de código abierto se originan allí. [34] Sin embargo, esto ha aumentado el enfoque en los derechos de patente dentro de estas licencias, lo que ha visto una reacción violenta de la comunidad OSS, que prefiere otras formas de protección de la propiedad intelectual . [34]

Otro problema incluye las medidas de protección tecnológica (TPM) y las técnicas de gestión de derechos digitales (DRM) que fueron reconocidas legalmente a nivel internacional y protegidas en el Tratado de la Organización Mundial de la Propiedad Intelectual (OMPI) de 1996. [34] A los defensores del software de código abierto no les gustaban estas tecnologías porque limitaban a los usuarios finales potencialmente más allá de la ley de derechos de autor. [34] Europa respondió a tales quejas poniendo las TPM bajo controles legales, lo que representó una victoria para los partidarios del OSS. [34]

Implicaciones económicas y empresariales

En las comunidades de código abierto, en lugar de poseer el software producido, el productor posee el desarrollo del software en evolución. [35] De esta manera, el futuro del software es abierto, lo que dificulta la propiedad intelectual dentro del OSS. [35] La concesión de licencias y la marca pueden impedir que otros lo roben, preservando su condición de bien público . [35] El software de código abierto puede considerarse un bien público, ya que está disponible para todos y no disminuye su valor para los demás cuando lo descarga una persona. [35] El software de código abierto es único en el sentido de que se vuelve más valioso a medida que se utiliza y se contribuye a él, en lugar de disminuir el recurso. Esto se explica por conceptos como la inversión en reputación y los efectos de red . [35]

El modelo económico del software de código abierto se puede explicar como que los desarrolladores contribuyen con su trabajo a los proyectos, creando beneficios públicos. [35] Los desarrolladores eligen proyectos en función de los beneficios o costos percibidos, como una mejor reputación o valor del proyecto. [35] Las motivaciones de los desarrolladores pueden provenir de muchos lugares y razones diferentes, pero la conclusión importante es que el dinero no es el único incentivo ni el más importante . [35]

Como la teoría económica se centra principalmente en el consumo de recursos escasos, la dinámica del OSS puede resultar difícil de entender. En el OSS, los productores se convierten en consumidores al cosechar las recompensas de contribuir a un proyecto. [35] Por ejemplo, un desarrollador se vuelve bien considerado por sus pares por su contribución exitosa a un proyecto de OSS. [35] Los beneficios sociales y las interacciones del OSS también son difíciles de tener en cuenta en los modelos económicos. [35] Además, la innovación tecnológica crea discusiones y perspectivas de valor que cambian constantemente, lo que hace que el modelo económico no pueda predecir el comportamiento social. [35]

Aunque el OSS es teóricamente un desafío para los modelos económicos, se puede explicar como una actividad social sostenible que requiere recursos. [35] Estos recursos incluyen tiempo, dinero, tecnología y contribuciones. [35] Muchos desarrolladores han utilizado tecnología financiada por organizaciones como universidades y gobiernos, aunque estas mismas organizaciones se benefician del trabajo realizado por el OSS. [35] A medida que el OSS crece, los sistemas híbridos que contienen OSS y sistemas propietarios se están volviendo más comunes. [35]

A mediados de la década de 2000, cada vez más empresas tecnológicas comenzaron a utilizar OSS. [24] Por ejemplo, Dell comenzó a vender computadoras con GNU/Linux ya instalado. [24] La propia Microsoft lanzó un sistema operativo basado en Linux a pesar de su animosidad previa con el movimiento OSS. [24] A pesar de estos avances, estas empresas tienden a utilizar OSS solo para ciertos propósitos, lo que genera preocupaciones de que las corporaciones se estén aprovechando de OSS y no estén recibiendo nada a cambio. [24]

Usos gubernamentales

Si bien muchos gobiernos están interesados ​​en implementar y promover software de código abierto debido a los muchos beneficios que brinda, un gran problema a considerar es la ciberseguridad . [36] Si bien las vulnerabilidades accidentales son posibles, también lo son los ataques de agentes externos. [36] Debido a estos temores, el interés gubernamental en contribuir a la gobernanza del software se ha vuelto más prominente. [36] Sin embargo, estos son los trazos generales del problema, ya que cada país tiene sus propias interacciones politizadas específicas con el software de código abierto y sus objetivos para su implementación. [36] Por ejemplo, Estados Unidos se ha centrado en la seguridad nacional con respecto a la implementación de software de código abierto debido a la amenaza percibida del aumento de la actividad de software de código abierto en países como China y Rusia, y el Departamento de Defensa está considerando múltiples criterios para usar OSS. [36] Estos criterios incluyen: si proviene y es mantenido por fuentes confiables, si continuará siendo mantenido, si hay dependencias de subcomponentes en el software, seguridad e integridad de los componentes e influencia gubernamental extranjera. [36]

Otro problema para los gobiernos en relación con el código abierto son sus inversiones en tecnologías como sistemas operativos , semiconductores , nube e inteligencia artificial . [36] Todas estas tecnologías tienen implicaciones para la cooperación global, lo que nuevamente abre problemas de seguridad y consecuencias políticas. [36] Muchos países tienen que equilibrar la innovación tecnológica con la dependencia tecnológica en estas asociaciones. [36] Por ejemplo, después de que a la empresa china de código abierto Huawei, dependiente del sistema operativo, se le impidiera utilizar el sistema Android de Google en 2019, comenzaron a crear su propio sistema operativo alternativo: Harmony OS . [36]

Alemania creó recientemente un Fondo Tecnológico Soberano para ayudar a respaldar la gobernanza y el mantenimiento del software que utilizan.

Movimiento de software abierto

Historia

En los primeros tiempos de la informática , como en los años 1950 y 1960, los programadores y desarrolladores compartían software para aprender unos de otros y hacer evolucionar el campo de la informática. [37] Por ejemplo, Unix incluía el código fuente del sistema operativo para los usuarios. [37] Con el tiempo, la comercialización de software en los años 1970-1980 comenzó a impedir esta práctica. [37] Sin embargo, los académicos todavía solían desarrollar software de forma colaborativa. [37]

En respuesta, el movimiento de código abierto nació del trabajo de entusiastas programadores expertos, ampliamente conocidos como hackers o cultura hacker . [38] Uno de estos entusiastas, Richard Stallman , fue una fuerza impulsora detrás del movimiento del software libre , que más tarde permitiría el movimiento de código abierto . [17] En 1984, renunció al MIT para crear un sistema operativo libre, GNU , después de que la cultura de programación en su laboratorio fuera sofocada por el software propietario que impedía que el código fuente se compartiera y mejorara. [17] GNU era compatible con UNIX, lo que significa que los entusiastas programadores aún estarían familiarizados con su funcionamiento. [17] Sin embargo, rápidamente se hizo evidente que había cierta confusión con la etiqueta que Stallman había elegido para el software libre , que describió como libre como en libertad de expresión, no cerveza gratis, refiriéndose al significado de libre como libertad en lugar de precio. [17] Más tarde amplió este concepto de libertad a las cuatro libertades esenciales. [17] A través de GNU, aparecieron las normas de código abierto de incorporación de código fuente de otros, correcciones de errores de la comunidad y sugerencias de código para nuevas características. [17] En 1985, Stallman fundó la Free Software Foundation (FSF) para promover cambios en el software y ayudar a escribir GNU. [17] Para evitar que su trabajo se usara en software propietario, Stallman creó el concepto de copyleft , que permitía el uso de su trabajo por parte de cualquier persona, pero bajo términos específicos. [17] Para ello, creó la Licencia Pública General de GNU (GNU GPL) en 1989, que se actualizó en 1991. [17] En 1991, GNU se combinó con el núcleo Linux escrito por Linus Torvalds , ya que faltaba un núcleo en GNU. [39] El sistema operativo ahora se conoce habitualmente como Linux . [17] A lo largo de todo este período, hubo muchos otros proyectos y licencias de software libre en ese momento, todos con ideas diferentes de lo que era y debía ser el concepto de software libre, así como la moralidad del software propietario, como Berkeley Software Distribution , TeX y el X Window System . [40]

A medida que se desarrollaba el software libre, la Free Software Foundation comenzó a buscar cómo llevar las ideas del software libre y los beneficios percibidos a la industria del software comercial . [40] Se concluyó que el activismo social de la FSF no era atractivo para las empresas y que necesitaban una forma de cambiar la marca del movimiento del software libre para enfatizar el potencial comercial de compartir y colaborar en el código fuente del software. [40] El término código abierto fue sugerido por Christine Peterson en 1998 en una reunión de partidarios del software libre. [17] Muchos en el grupo sintieron que el nombre software libre era confuso para los recién llegados y frenaba el interés de la industria y aceptaron fácilmente la nueva designación de código abierto, creando la Iniciativa de Código Abierto (OSI) y la definición OSI de lo que es el software de código abierto. [17] La ​​definición de la Iniciativa de Código Abierto (OSI) ahora es reconocida por varios gobiernos a nivel internacional como la definición estándar o de facto . [39] La definición se basó en las Pautas de Software Libre de Debian , escritas y adaptadas principalmente por Bruce Perens. [41] La definición de OSI se diferencia de la definición de software libre en que permite la inclusión de software propietario y permite más libertades en su licencia. [17] Algunos, como Stallman, están más de acuerdo con el concepto original de software libre como resultado porque adopta una postura moral fuerte contra el software propietario, aunque hay mucha superposición entre los dos movimientos en términos del funcionamiento del software. [17]

Mientras que la Iniciativa de Código Abierto buscaba alentar el uso del nuevo término y evangelizar los principios a los que se adhería, los vendedores de software comercial se vieron cada vez más amenazados por el concepto de software distribuido libremente y acceso universal al código fuente de una aplicación , con un ejecutivo de Microsoft llamando al código abierto un destructor de propiedad intelectual en 2001. [42] Sin embargo, mientras que el software libre y de código abierto (FOSS) históricamente ha jugado un papel fuera del desarrollo de software privado convencional, compañías tan grandes como Microsoft han comenzado a desarrollar presencias oficiales de código abierto en Internet. [42] IBM, Oracle y State Farm son sólo algunas de las compañías con una participación pública seria en el competitivo mercado de código abierto actual, marcando un cambio significativo en la filosofía corporativa con respecto al desarrollo de FOSS. [42]

Futuro

El futuro de la comunidad de software de código abierto, y de la comunidad de software libre por extensión, ha sido exitoso, si bien no ha sido confuso en cuanto a lo que representa. [24] Por ejemplo, Android y Ubuntu son ejemplos de hitos de éxito en el ascenso del software de código abierto a la prominencia desde los márgenes de la innovación tecnológica tal como existía a principios de la década de 2000. [24] Sin embargo, algunos en la comunidad los consideran fracasos en su representación del OSS debido a problemas como la minimización del centro OSS de Android por parte de Google y sus socios, el uso de una licencia Apache que permitió la bifurcación y resultó en una pérdida de oportunidades de colaboración dentro de Android, la priorización de la conveniencia sobre la libertad en Ubuntu y las características dentro de Ubuntu que rastrean a los usuarios con fines de marketing. [24]

El uso de OSS se ha vuelto más común en los negocios, con un 78% de compañías informando que ejecutan todas o parte de sus operaciones en FOSS. [24] La popularidad de OSS ha aumentado hasta el punto de que Microsoft , un detractor de OSS, ha incluido su uso en sus sistemas. [24] Sin embargo, este éxito ha generado preocupaciones que determinarán el futuro de OSS ya que la comunidad debe responder preguntas como qué es OSS, qué debería ser y qué se debe hacer para protegerlo, si es que necesita protección. [24] En general, si bien la revolución libre y de código abierto se ha desacelerado hasta un equilibrio percibido en el mercado, eso no significa que haya terminado, ya que deben llevarse a cabo muchas discusiones teóricas para determinar su futuro. [24]

Comparaciones con otros modelos de desarrollo y licenciamiento de software

Software propietario/de código cerrado

El software de código abierto se diferencia del software propietario en que está disponible públicamente, la licencia no requiere tarifas y se permiten modificaciones y distribuciones bajo especificaciones de licencia. [43] Todo esto funciona para evitar un monopolio en cualquier producto OSS, que es un objetivo del software propietario. [43] El software propietario limita las opciones de sus clientes a comprometerse a usar ese software, actualizarlo o cambiar a otro software, lo que obliga a los clientes a ver sus preferencias de software afectadas por su costo monetario. [43] El escenario ideal para el proveedor de software propietario sería un bloqueo , donde el cliente no cambia o no puede cambiar de software debido a estos costos y continúa comprando productos de ese proveedor. [43]

En el caso del software propietario, las correcciones de errores solo las puede proporcionar el proveedor, el cambio de plataforma requiere otra compra y la existencia del producto depende del proveedor, que puede discontinuarlo en cualquier momento. [38] Además, el software propietario no proporciona su código fuente y los usuarios no pueden modificarlo. [17] Para las empresas, esto puede representar un riesgo de seguridad y una fuente de frustración, ya que no pueden especializar el producto según sus necesidades y puede haber amenazas ocultas o fugas de información dentro del software a las que no pueden acceder ni modificar. [17]

Software libre

Según la definición de OSI, el código abierto es una licencia de software amplia que pone el código fuente a disposición del público en general con restricciones relajadas o inexistentes sobre el uso y la modificación del código. [44] Una característica explícita del código abierto es que impone muy pocas restricciones al uso o la distribución por parte de cualquier organización o usuario, con el fin de permitir la rápida evolución del software. [44]

Richard Stallman , líder del movimiento de software libre y miembro de la Free Software Foundation, se opone a que el término código abierto se aplique a lo que ellos denominan software libre. [13] Aunque está de acuerdo en que los dos términos describen casi la misma categoría de software, Stallman considera que equiparar los términos es incorrecto y engañoso. [13] Cree que la principal diferencia es que al elegir un término sobre el otro, los demás sepan cuáles son los objetivos de uno: desarrollo (código abierto) o una postura social (software libre). [45] Sin embargo, existe una superposición significativa entre el software de código abierto y el software libre. [13] Stallman también se opone al pragmatismo profesado por la Open Source Initiative , ya que teme que los ideales del software libre de libertad y comunidad se vean amenazados al comprometer los estándares idealistas de la FSF para la libertad del software. [45] La FSF considera que el software libre es un subconjunto del software de código abierto, y Richard Stallman explicó que el software DRM , por ejemplo, puede desarrollarse como código abierto, a pesar de cómo restringe a sus usuarios, y por lo tanto no califica como software libre. [13]

La FSF afirmó que el término código abierto fomenta una ambigüedad de otro tipo, ya que confunde la mera disponibilidad del código fuente con la libertad de usarlo, modificarlo y redistribuirlo. [13] Por otra parte, el término software libre fue criticado por la ambigüedad de la palabra libre, que se consideró desalentadora para la adopción empresarial, y por el uso ambiguo histórico del término. [45]

Los desarrolladores han utilizado los términos alternativos Software Libre y de Código Abierto ( FOSS ), o Software Libre/Libre y de Código Abierto (FLOSS), en consecuencia, para describir el software de código abierto que también es software libre . [28]

Software de código fuente disponible

El software puede distribuirse con código fuente , que es un código que es legible. [46] El software está disponible en código fuente cuando este código fuente está disponible para ser visto. [46] Sin embargo, para estar disponible en código fuente o FOSS , el código fuente no necesita ser accesible para todos, solo para los usuarios de ese software. [46] Si bien todo el software FOSS está disponible en código fuente porque este es un requisito establecido por la Definición de Código Abierto , no todo el software disponible en código fuente es FOSS. [46] Por ejemplo, si el software no cumple con otros aspectos de la Definición de Código Abierto, como la modificación o redistribución permitidas, incluso si el código fuente está disponible, el software no es FOSS. [46]

Código abierto

Una tendencia reciente dentro de las empresas de software es el código abierto, o la transición de su software propietario anterior a software de código abierto mediante su lanzamiento bajo una licencia de código abierto . [47] [48] Ejemplos de empresas que han hecho esto son Google, Microsoft y Apple. [47] Además, el código abierto puede referirse a la programación de software de código abierto o la instalación de software de código abierto. [48] El código abierto puede ser beneficioso de múltiples maneras, como atraer más contribuyentes externos que aportan nuevas perspectivas y capacidades de resolución de problemas. [47] Las desventajas del código abierto incluyen el trabajo que se debe hacer para mantener la nueva comunidad, como hacer que el código base sea fácilmente comprensible, establecer canales de comunicación para nuevos desarrolladores y crear documentación para permitir que los nuevos desarrolladores se unan fácilmente. [47] Sin embargo, una revisión de varios proyectos de código abierto encontró que, aunque un proyecto de código abierto recientemente atrae a muchos recién llegados, es probable que una gran cantidad abandone pronto el proyecto y también es probable que sus bifurcaciones no tengan impacto. [47]

Otro

Otros conceptos que pueden compartir algunas similitudes con el código abierto son shareware , software de dominio público , freeware y visores/lectores de software que están disponibles gratuitamente pero no proporcionan el código fuente. [17] Sin embargo, estos difieren del software de código abierto en el acceso al código fuente , licencias, derechos de autor y tarifas. [17]

Sociedad y cultura

Demografía

A pesar de poder colaborar internacionalmente, se encontró que los contribuyentes de software de código abierto se encontraban principalmente en grandes clústeres como Silicon Valley que colaboran en gran medida entre sí. [49] Las posibles razones de este fenómeno pueden ser que la demografía de contribuyentes de OSS trabaja en gran medida en software, lo que significa que la ubicación geográfica de OSS está estrechamente relacionada con esa dispersión y las colaboraciones podrían fomentarse a través del trabajo y las redes sociales . [49] La aceptación del código puede verse afectada por el estatus dentro de estos clústeres de redes sociales, lo que crea predisposiciones injustas en la aceptación del código en función de la ubicación. [50] Las barreras a la colaboración internacional también incluyen diferencias lingüísticas o culturales. [51] Además, se ha demostrado que cada país tiene una mayor tasa de aceptación del código de los contribuyentes dentro de su país, excepto India, lo que indica un sesgo hacia colaboradores culturalmente similares. [51]

En 2021, los países con mayores contribuciones de software de código abierto incluyeron a Estados Unidos, China, Alemania, India y el Reino Unido, en ese orden. [49] Los países con la mayor cantidad de desarrolladores de OSS per cápita según un estudio en 2021 incluyen, en orden, Islandia, Suiza, Noruega, Suecia y Finlandia, mientras que en 2008 los países con la mayor cantidad de contribuyentes estimados en SourceForge fueron Estados Unidos, Alemania, Reino Unido, Canadá y Francia. [49] [51] Aunque se han realizado varios estudios sobre la distribución y las contribuciones de los desarrolladores de OSS, este sigue siendo un campo abierto que se puede medir de varias formas diferentes. [51] Por ejemplo, se ha demostrado que la participación en la tecnología de la información y la comunicación, la población, la riqueza y la proporción de acceso a Internet están correlacionadas con las contribuciones de OSS. [51]

Aunque se ha descubierto que la diversidad de género mejora la productividad del equipo, las mujeres aún enfrentan prejuicios al contribuir a proyectos de software de código abierto cuando su género es identificable. [52] En 2002, solo el 1,5% de los desarrolladores de software de código abierto internacionales eran mujeres, mientras que las mujeres representaban el 28% de los roles en la industria tecnológica, lo que demuestra su baja representación en el campo del software. [53] A pesar de que las contribuciones de OSS no tienen requisitos previos, este sesgo de género puede seguir existiendo debido a la creencia común de los contribuyentes de que el género no debería importar y la calidad del código debería ser la única consideración para la aceptación del código, lo que impide que la comunidad aborde las disparidades sistémicas en la representación femenina. [38] Sin embargo, una cifra más reciente de participación femenina en OSS calculada a nivel internacional entre 2005 y 2021 es del 9,8%, y la mayoría son contribuyentes recientes, lo que indica que la participación femenina puede estar creciendo. [54]

Motivaciones

Existen muchas motivaciones para contribuir a la comunidad OSS. [28] Por un lado, es una oportunidad para aprender y practicar múltiples habilidades como codificación y otras habilidades relacionadas con la tecnología, pero también habilidades fundamentales como comunicación y colaboración y habilidades prácticas necesarias para sobresalir en campos relacionados con la tecnología como el seguimiento de problemas o el control de versiones . [28] En lugar de aprender a través de un aula o un trabajo, aprender contribuyendo a OSS permite a los participantes aprender a su propio ritmo y seguir lo que les interesa. [28] Al contribuir a OSS, el colaborador puede aprender las mejores prácticas, tecnología y tendencias actuales de la industria e incluso tener la oportunidad de contribuir a la próxima gran innovación a medida que el OSS se vuelve cada vez más popular dentro del campo de la tecnología. [28] Contribuir a OSS sin pago significa que no hay amenaza de ser despedido, aunque la reputación puede verse afectada. [28] Por otro lado, una gran motivación para contribuir a OSS es la reputación que se gana a medida que uno hace crecer su cartera pública. [28]

Disparidades

Aunque la programación fue vista originalmente como una profesión femenina, sigue habiendo una gran brecha en la informática. [55] La identidad social tiende a ser una gran preocupación ya que las mujeres en la industria tecnológica enfrentan inseguridad por atraer atención masculina no deseada y acoso o ser poco femeninas en su conocimiento tecnológico, lo que tiene un gran impacto en la confianza. [38] Algunos participantes masculinos en el sector tecnológico dejan en claro que creen que es imposible que las mujeres encajen en la cultura, lo que aumenta la inseguridad de las mujeres y su lugar en la industria tecnológica. [52] Además, incluso en un entorno de contribución voluntaria como el software de código abierto, las mujeres tienden a terminar haciendo los aspectos menos técnicos de los proyectos, como las pruebas manuales o la documentación a pesar de que las mujeres y los hombres muestran la misma productividad en las contribuciones de OSS. [52] Los sesgos explícitos incluyen un mayor tiempo de retroalimentación, un mayor escrutinio del código y una menor tasa de aceptación del código. [52] Específicamente en la comunidad de software de código abierto, las mujeres informan que el lenguaje sexualmente ofensivo es común y se le da más atención a la identidad de las mujeres como mujeres que como contribuyentes de OSS. [38] El sesgo es difícil de abordar debido a la creencia de que el género no debería importar, y la mayoría de los contribuyentes sienten que es injusto que las mujeres reciban un trato especial y que el éxito debería depender de la habilidad, lo que impide cualquier cambio para ser más inclusivos. [38]

Adopción y aplicación

Proyectos clave

Los proyectos de software de código abierto son creados y mantenidos por una red de programadores, que a menudo pueden ser voluntarios, y se utilizan ampliamente tanto en productos gratuitos como comerciales. [56]

Unix : Unix es un sistema operativo creado por AT&T que comenzó como precursor del software de código abierto en el sentido de que la revolución del software libre y de código abierto comenzó cuando los desarrolladores comenzaron a intentar crear sistemas operativos sin código Unix. [24] Unix fue creado en la década de 1960, antes de la comercialización de software y antes de que el concepto de software de código abierto fuera necesario, por lo tanto, no se consideró un verdadero proyecto de software de código abierto. [24] Comenzó como un proyecto de investigación antes de comercializarse a mediados de la década de 1980. [24] Antes de su comercialización, representaba muchos de los ideales sostenidos por la revolución del software libre y de código abierto, incluida la colaboración descentralizada de usuarios globales, lanzamientos continuos y una cultura comunitaria de desagrado hacia el software propietario . [24]

BSD: Berkeley Software Distribution (BSD) es un sistema operativo que comenzó como una variante de Unix en 1978 que mezclaba código Unix con código de los laboratorios Berkeley para aumentar la funcionalidad. [24] Como BSD se centró en aumentar la funcionalidad, compartiría públicamente sus mayores innovaciones con el sistema operativo Unix principal. [24] Este es un ejemplo de la compartición de código público libre que es una característica central del software libre actual. [24] Cuando Unix se comercializó en la década de 1980, los desarrolladores o miembros de la comunidad que no apoyaban el software propietario comenzaron a centrarse en BSD y a convertirlo en un sistema operativo que no incluía ningún código de Unix. [24] La versión final de BSD se lanzó en 1995. [24]

GNU : GNU es un sistema operativo libre creado por Richard Stallman en 1984 cuyo nombre significa Gnu no es Unix. [24] La idea era crear un sistema operativo alternativo a Unix que estuviera disponible para que cualquiera lo usara y permitiera a los programadores compartir código libremente entre ellos. [24] Sin embargo, el objetivo de GNU no era solo reemplazar a Unix, sino hacer una versión superior que tuviera más capacidades tecnológicas. [24] Fue lanzado antes de que las creencias filosóficas de la revolución del software libre y de código abierto estuvieran verdaderamente definidas. [24] Debido a su creación por el destacado programador de FOSS Richard Stallman, GNU estuvo muy involucrado en el activismo de FOSS, y uno de los mayores logros de GNU fue la creación de la Licencia Pública General de GNU o GPL, que permitió a los desarrolladores lanzar software que pudiera compartirse y modificarse legalmente. [24]

Linux : Linux es un núcleo de sistema operativo que fue introducido en 1991 por Linus Torvalds . [24] Linux se inspiró en la creación de una versión mejorada del servicio operativo con fines de lucro Minux . [24] Era radicalmente diferente de lo que otros hackers estaban produciendo en ese momento debido a que era totalmente gratuito y estaba descentralizado. [24] Más tarde, Linux se puso bajo la licencia GPL , lo que permitió a las personas ganar dinero con Linux y llevar Linux a la comunidad FOSS. [24]

Apache: Apache comenzó en 1995 como una colaboración entre un grupo de desarrolladores que lanzaron su propio servidor web debido a su frustración con la base de código HTTPd de NCSA . [24] El nombre Apache se usó debido a los varios parches que aplicaron a esta base de código. [24] Un año después de su lanzamiento, se convirtió en el servidor web líder a nivel mundial . [24] Pronto, Apache lanzó su propia licencia , creando discordia en la gran comunidad FOSS, aunque finalmente resultó exitosa. [24] La licencia Apache permitió a los miembros autorizados acceder directamente al código fuente, una marcada diferencia con los enfoques de GNU y Linux. [24]

Extensiones para uso no relacionado con software

Si bien el término código abierto se aplicaba originalmente solo al código fuente del software, ahora se está aplicando a muchas otras áreas, como la ecología de código abierto , un movimiento para descentralizar las tecnologías para que cualquier ser humano pueda usarlas. [13] [57] Sin embargo, a menudo se aplica incorrectamente a otras áreas que tienen principios diferentes y en competencia, que se superponen solo parcialmente. [38]

Los mismos principios que sustentan el software de código abierto se pueden encontrar en muchas otras iniciativas, como el código abierto, el contenido abierto y la colaboración abierta . [58] [3]

Esta "cultura" o ideología sostiene que los principios se aplican de manera más general para facilitar la aportación simultánea de diferentes agendas, enfoques y prioridades, en contraste con modelos de desarrollo más centralizados como los que se utilizan normalmente en las empresas comerciales. [15]

Valor

Más del 90 por ciento de las empresas utilizan software de código abierto como un componente de su software propietario. [59] La decisión de utilizar software de código abierto, o incluso participar en proyectos de código abierto para mejorar el software de código abierto existente, es típicamente una decisión empresarial pragmática. [60] [61] Cuando el software propietario compite directamente con una alternativa de código abierto, la investigación ha encontrado resultados contradictorios sobre el efecto de la competencia en el precio y la calidad del producto propietario. [62]

Durante décadas, algunas empresas han hecho del mantenimiento de un producto de software de código abierto para usuarios empresariales su modelo de negocio. Estas empresas controlan un producto de software de código abierto y, en lugar de cobrar por la licencia o el uso, cobran por las mejoras, la integración y otros servicios. [63] Los productos de software como servicio (SaaS) basados ​​en componentes de código abierto son cada vez más comunes. [64]

Se prefiere el software de código abierto para aplicaciones científicas porque aumenta la transparencia y ayuda en la validación y aceptación de los resultados científicos. [65]

Véase también

Referencias

  1. ^ St. Laurent, Andrew M. (2008). Entender el código abierto y las licencias de software libre. O'Reilly Media. pág. 4. ISBN 978-0-596-55395-1Archivado desde el original el 22 de abril de 2023 . Consultado el 21 de marzo de 2023 .
  2. ^ Corbly, James Edward (25 de septiembre de 2014). «La alternativa del software libre: software libre, software de código abierto y bibliotecas». Tecnologías de la información y bibliotecas . 33 (3): 65. doi : 10.6017/ital.v33i3.5105 . ISSN  2163-5226. Archivado desde el original el 1 de mayo de 2021 . Consultado el 28 de abril de 2021 .
  3. ^ ab Levine, Sheen S.; Prietula, Michael J. (30 de diciembre de 2013). "Colaboración abierta para la innovación: principios y desempeño". Ciencias de la organización . 25 (5): 1414–1433. arXiv : 1406.7541 . doi :10.1287/orsc.2013.0872. ISSN  1047-7039. S2CID  6583883.
  4. ^ Hoffmann, Manuel; Nagle, Frank; Zhou, Yanuo (2024). "El valor del software de código abierto". Revista electrónica SSRN . doi :10.2139/ssrn.4693148. ISSN  1556-5068.
  5. ^ "Autoridad y reconocimiento internacionales". Opensource.org. 21 de abril de 2015. Archivado desde el original el 23 de julio de 2019. Consultado el 7 de diciembre de 2017 .
  6. ^ Perens, Bruce. Fuentes abiertas: voces de la revolución del código abierto Archivado el 15 de septiembre de 2014 en Wayback Machine . O'Reilly Media . 1999.
  7. ^ Dibona, Chris; Ockman, Sam (enero de 1999). La definición de código abierto, de Bruce Perens. O'Reilly. ISBN 978-1-56592-582-3.
  8. ^ "La definición de código abierto". 7 de julio de 2006. Archivado desde el original el 15 de octubre de 2013. Consultado el 24 de agosto de 2008 .La definición de código abierto según la Iniciativa de Código Abierto
  9. ^ "¿Cuántas licencias de código abierto necesitas? – Slashdot". News.slashdot.org . 16 de febrero de 2009. Archivado desde el original el 17 de julio de 2013 . Consultado el 25 de marzo de 2012 .
  10. ^ Iniciativa de Código Abierto (24 de julio de 2006). «La definición de código abierto (anotada)». opensource.org . Archivado desde el original el 5 de mayo de 2021 . Consultado el 22 de julio de 2016 .
  11. ^ Feller, Joseph; Fitzgerald, Brian; Hissam, Scott; Lakhani, Karim R. (2005). "Introducción". Perspectivas sobre el software libre y de código abierto . Cambridge, MA: The MIT Press. pp. xvii. ISBN 0-262-06246-1.
  12. ^ Tiemann, Michael. «Historia de la OSI». Iniciativa de código abierto. Archivado desde el original el 24 de septiembre de 2006. Consultado el 13 de mayo de 2014 .
  13. ^ abcdefgh Stallman, Richard (2007). "Por qué el código abierto no entiende el sentido del software libre".
  14. ^ Stallman, Richard (19 de junio de 2007). «Por qué el «software libre» es mejor que el «código abierto»». Filosofía del proyecto GNU . Free Software Foundation. Archivado desde el original el 27 de marzo de 2021. Consultado el 23 de julio de 2007 .
  15. ^ abcdefghij Raymond, Eric (2005). "La Catedral y el Bazar (publicado originalmente en el Volumen 3, Número 3, marzo de 1998)". Primer Lunes . doi : 10.5210/fm.v0i0.1472 . ISSN  1396-0466.
  16. ^ abcdefghijklmnopqrs Robles, Gregorio (2006). "Investigación empírica de ingeniería de software sobre software libre/libre/de código abierto". 22.ª Conferencia Internacional IEEE sobre Mantenimiento de Software, 2006. págs. 347–350. doi :10.1109/icsm.2006.25. ISBN 0-7695-2354-4. S2CID  6589566 . Consultado el 21 de noviembre de 2023 .
  17. ^ abcdefghijklmnopqrs Napoleao, Bianca M.; Petrillo, Fabio; Halle, Sylvain (2020). "Proceso de desarrollo de software de código abierto: una revisión sistemática". 2020 IEEE 24th International Enterprise Distributed Object Computing Conference (EDOC) . IEEE. págs. 135–144. arXiv : 2008.05015 . doi :10.1109/EDOC49727.2020.00025. ISBN 978-1-7281-6473-1.
  18. ^ abcdefghijklmn Napoleao, Bianca M.; Petrillo, Fabio; Halle, Sylvain (2020). "Proceso de desarrollo de software de código abierto: una revisión sistemática". 2020 IEEE 24th International Enterprise Distributed Object Computing Conference (EDOC) . IEEE. págs. 135–144. arXiv : 2008.05015 . doi :10.1109/EDOC49727.2020.00025. ISBN 978-1-7281-6473-1.
  19. ^ Departamento de Defensa de Estados Unidos. «Preguntas frecuentes sobre software de código abierto». Director de Información . Archivado desde el original el 28 de agosto de 2016. Consultado el 22 de julio de 2016 .
  20. ^ Sharma, Srinarayan; Vijayan Sugumaran; Balaji Rajagopalan (2002). "Un marco para crear comunidades de software híbrido de código abierto" (PDF) . Revista de sistemas de información . 12 : 7–25. doi :10.1046/j.1365-2575.2002.00116.x. S2CID  5815589. Archivado (PDF) desde el original el 30 de octubre de 2008 . Consultado el 8 de septiembre de 2008 .
  21. ^ ab Reynolds, Carl; Jeremy Wyatt (febrero de 2011). "Código abierto, estándares abiertos y sistemas de información de atención médica". Revista de investigación médica en Internet . 13 (1): e24. doi : 10.2196/jmir.1521 . PMC 3221346 . PMID  21447469. 
  22. ^ Landry, John; Rajiv Gupta (septiembre de 2000). "Profiting from Open Source" (Beneficiarse del código abierto). Harvard Business Review . doi :10.1225/F00503 (inactivo el 1 de noviembre de 2024).{{cite journal}}: CS1 maint: DOI inactivo a partir de noviembre de 2024 ( enlace )
  23. ^ abc Nagle, Frank (3 de marzo de 2019). "Política tecnológica gubernamental, valor social y competitividad nacional" (PDF) . Revista de sistemas de información . 12 . doi :10.2139/ssrn.3355486. S2CID  85509685. SSRN  3355486.
  24. ^ abcdefghijklmnopqrstu vwxyz aa ab ac ad ae af ag ah ai aj Tozzi, Christopher (2017). Por diversión y lucro: una historia de la revolución del software libre y de código abierto . Estados Unidos: MIT Press. ISBN 978-0-262-34118-9.
  25. ^ Plotkin, Hal (diciembre de 1998). "Qué (y por qué) debería saber sobre el software de código abierto". Harvard Management Update : 8–9.
  26. ^ abc Payne, Christian (febrero de 2002). "Sobre la seguridad del software de código abierto". Revista de sistemas de información . 12 (1): 61–78. doi :10.1046/j.1365-2575.2002.00118.x. S2CID  8123076.
  27. ^ abcd Zolkifli, Nazatul Nurlisa; Ngah, Amir; Deraman, Aziz (2018). "Sistema de control de versiones: una revisión". Procedia Ciencias de la Computación . 135 : 408–415. doi : 10.1016/j.procs.2018.08.191 .
  28. ^ abcdefghijklmnopqrstu Brasseur, VM (2018). Forja tu futuro con código abierto: desarrolla tus habilidades, desarrolla tu red, desarrolla el futuro de la tecnología . Los programadores pragmáticos. Raleigh, Carolina del Norte: The Pragmatic Bookshelf. ISBN 978-1-68050-301-2.
  29. ^ "Código abierto". Open Collective . 20 de octubre de 2022 . Consultado el 28 de mayo de 2024 .
  30. ^ "Tecnologías". Fondo Tecnológico Soberano . Consultado el 28 de mayo de 2024 .
  31. ^ "NSF invierte más de 26 millones de dólares en proyectos de código abierto | NSF - National Science Foundation". new.nsf.gov . 25 de octubre de 2023 . Consultado el 28 de mayo de 2024 .
  32. ^ abcd Spinellis, Diomidis; Giannikas, Vaggelis (2012). "Adopción organizacional de software de código abierto". Revista de sistemas y software . 85 (3): 666–682. doi :10.1016/j.jss.2011.09.037.
  33. ^ Zhang, Yiming; Malhotra, Baljeet; Chen, Cheng (2018). "Análisis de la seguridad de código abierto en toda la industria". 2018 16.ª Conferencia anual sobre privacidad, seguridad y confianza (PST) . IEEE. págs. 1–10. doi :10.1109/PST.2018.8514185. ISBN . 978-1-5386-7493-2. Número de identificación del sujeto  53234981.
  34. ^ abcdefghijklmnopqrstu vwxyz Brock, Amanda (2023). Derecho, política y práctica de código abierto (2.ª ed.). Reino Unido: Oxford University Press. ISBN 978-0-19-886234-5.
  35. ^ abcdefghijklmnop Wynants, M., & Cornelis, J. (Eds.). (2005). ¿Qué tan abierto es el futuro? : Escenarios económicos, sociales y culturales inspirados en software libre y de código abierto . ASP.
  36. ^ abcdefghij Pannier, Alice (2022). El poder del software: las implicaciones económicas y geopolíticas del software de código abierto . Études de l'Ifri. ISBN 979-10-373-0641-8.
  37. ^ abcd Maracke, Catharina (2019). "Software libre y de código abierto y licencias de patentes basadas en FRAND: cómo mediar entre la patente esencial estándar y el software libre y de código abierto". Revista de propiedad intelectual mundial . 22 (3–4): 78–102. doi : 10.1111/jwip.12114 . ISSN  1422-2213.
  38. ^ abcdefg Bretthauer, David (2001). "Software de código abierto: una historia". Tecnologías de la información y bibliotecas . 21 (1).
  39. ^ ab "Autoridad y reconocimiento internacional". Iniciativa de código abierto . 21 de abril de 2015. Consultado el 18 de diciembre de 2023 .
  40. ^ abc Fogel, Karl (2006). Producción de software de código abierto: cómo ejecutar con éxito un proyecto de software libre (1.ª edición, [Nachdr.] ed.). Pekín, Colonia: O'Reilly. ISBN 978-0-596-00759-1.
  41. ^ Kelty, Christopher (2008). Dos bits: el significado cultural del software libre . Duke University Press. ISBN 978-0-8223-8900-2.
  42. ^ abc Miller, Keith W.; Voas, Jeffrey; Costello, Tom (2010). "Software libre y de código abierto". IT Professional . 12 (6): 14–16. doi :10.1109/mitp.2010.147. ISSN  1520-9202. S2CID  265508713.
  43. ^ abcd Zhu, Kevin Xiaoguo; Zhou, Zach Zhizhong (2012). "Nota de investigación: estrategia de bloqueo en la competencia de software: software de código abierto frente a software propietario". Investigación de sistemas de información . 23 (2): 536–545. doi :10.1287/isre.1110.0358. ISSN  1047-7047.
  44. ^ ab "La definición de código abierto (anotada)". Iniciativa de código abierto . 24 de julio de 2006. Consultado el 18 de diciembre de 2023 .
  45. ^ abc Stallman, Richard M.; Gay, Joshua (2002). Software libre, sociedad libre . Boston (Massachusetts): Fundación para el software libre. ISBN 978-1-882114-98-6.
  46. ^ abcde Fortunato, Laura; Galassi, Mark (17 de mayo de 2021). "El caso del software libre y de código abierto en la investigación y la erudición". Philosophical Transactions of the Royal Society A: Mathematical, Physical and Engineering Sciences . 379 (2197). Bibcode :2021RSPTA.37900079F. doi :10.1098/rsta.2020.0079. ISSN  1364-503X. PMID  33775148. S2CID  232387092.
  47. ^ abcde Pinto, Gustavo; Steinmacher, Igor; Dias, Luiz Felipe; Gerosa, Marco (2018). "Sobre los desafíos de los proyectos de software propietario de código abierto". Ingeniería de software empírica . 23 (6): 3221–3247. doi :10.1007/s10664-018-9609-6. ISSN  1382-3256. S2CID  254467440.
  48. ^ ab Ågerfalk; Fitzgerald (2008). "Subcontratación a una fuerza laboral desconocida: exploración del opensurcing como estrategia de abastecimiento global". MIS Quarterly . 32 (2): 385. doi :10.2307/25148845. ISSN  0276-7783. JSTOR  25148845.
  49. ^ abcd Wachs, Johannes; Nitecki, Mariusz; Schueller, William; Polleres, Axel (marzo de 2002). "La geografía del software de código abierto: evidencia de GitHub". Pronóstico tecnológico y cambio social . 176 : 121478. arXiv : 2107.03200 . doi :10.1016/j.techfore.2022.121478.
  50. ^ Rastogi, Ayushi; Nagappan, Nachiappan; Gousios, Georgios; van der Hoek, André (11 de octubre de 2018). "Relación entre la ubicación geográfica y la evaluación de las contribuciones de los desarrolladores en GitHub". Actas del 12.º Simposio internacional ACM/IEEE sobre ingeniería y medición de software empírico. ACM. págs. 1–8. doi :10.1145/3239235.3240504. ISBN . 978-1-4503-5823-1.S2CID215822439  .​
  51. ^ abcde González-Barahona, Jesús M.; Robles, Gregorio; Andradas-Izquierdo, Roberto; Ghosh, Rishab Aiyer (agosto de 2008). "Origen geográfico de los desarrolladores de software libre". Economía y política de la información . 20 (4): 356–363. doi :10.1016/j.infoecopol.2008.07.001.
  52. ^ abcd Bosu, Amiangshu; Sultana, Kazi Zakia (2019). "Diversidad e inclusión en proyectos de software de código abierto (OSS): ¿dónde nos encontramos?". Simposio internacional ACM/IEEE de 2019 sobre ingeniería y medición de software empírico (ESEM) . IEEE. págs. 1–11. doi :10.1109/ESEM.2019.8870179. ISBN . 978-1-7281-2968-6.S2CID 197640269  .
  53. ^ Nafus, Dawn (junio de 2012). "'Los parches no tienen género': qué es lo que no es abierto en el software de código abierto". New Media & Society . 14 (4): 669–683. doi :10.1177/1461444811422887. ISSN  1461-4448. S2CID  206727320.
  54. ^ Trinkenreich, Bianca; Wiese, Igor; Sarma, Anita; Gerosa, Marco; Steinmacher, Igor (31 de octubre de 2022). "Participación de las mujeres en el software de código abierto: un estudio de la literatura". ACM Transactions on Software Engineering and Methodology . 31 (4): 1–37. arXiv : 2105.08777 . doi :10.1145/3510460. ISSN  1049-331X. S2CID  234778104.
  55. ^ Albusays, Khaled; Bjorn, Pernille; Dabbish, Laura; Ford, Denae; Murphy-Hill, Emerson; Serebrenik, Alexander; Storey, Margaret-Anne (abril de 2021). "La crisis de diversidad en el desarrollo de software". IEEE Software . 38 (2): 19–25. doi :10.1109/MS.2020.3045817. ISSN  0740-7459.
  56. ^ Popp, Karl Michael, ed. (2020). Mejores prácticas para el uso comercial de software de código abierto: modelos de negocio, procesos y herramientas para la gestión de software de código abierto . Academia Synomic. Norderstedt: BoD – Libros a pedido. ISBN 978-3-7386-1909-6.
  57. ^ Powers, Stephen M.; Hampton, Stephanie E. (2019). "Ciencia abierta, reproducibilidad y transparencia en ecología". Aplicaciones ecológicas . 29 (1): e01822. Bibcode :2019EcoAp..29E1822P. doi : 10.1002/eap.1822 . ISSN  1051-0761. PMID  30362295.
  58. ^ Cheliotis, Giorgos (2009). "Del código abierto al contenido abierto: Organización, concesión de licencias y procesos de decisión en la producción cultural abierta". Sistemas de apoyo a la toma de decisiones . 47 (3): 229–244. doi :10.1016/j.dss.2009.02.006. ISSN  0167-9236.
  59. ^ Butler y otros. 2022, pág. 1.
  60. ^ Mayordomo y col. 2022, pág. 11152.
  61. ^ Dávila 2015, pág. 7.
  62. ^ Zhou y Choudhary 2022, pág. 731.
  63. ^ Agosto y col. 2021, págs. 1-2.
  64. ^ Agosto et al. 2021, pág. 1.
  65. ^ Morin et al. 2012, Compatibilidad, proliferación, fragmentación y direccionalidad.

Lectura adicional

Enlaces externos