¿Cómo se sustenta económicamente el desarrollo de software GNU?

Pido disculpas si esta pregunta está fuera de tema, pero es simultáneamente una pregunta de economía y de programación. Si debe ir a otra comunidad SE, por favor indíqueme.

En teoría, el software GNU está completamente desarrollado por voluntarios durante su tiempo libre, o por empresas que financian voluntariamente a programadores para desarrollar software GNU (utilizando los ingresos de otro sector de su actividad).

Entiendo cómo puede funcionar perfectamente bien para proyectos a pequeña escala que un solo individuo puede realizar en un par de fines de semana lluviosos (digamos, por ejemplo, un juego de sudoku), porque después de todo, la programación de computadoras es un pasatiempo extremadamente divertido y gratificante, y no tengo ningún problema en ver personas que desarrollan programas pequeños o medianos durante su tiempo libre y compartirlas con el mundo.

El problema es que esto se escala extremadamente mal para programas más grandes por las siguientes razones:

1. Tan divertido como es la programación, a medida que el proyecto que debe implementarse se hace más grande, el tiempo que lleva implementar la funcionalidad deseada crece extremadamente rápido. Un programa a mayor escala requiere una cantidad increíble de tiempo para desarrollarse, por ejemplo, podría llevar 15 años de tiempo libre y vacaciones para que un individuo programe un sistema operativo, y para cuando se lance su software, será completamente obsoleto .
2. Como otras personas escriben programas de otra manera que lo hubiera hecho, leer y comprender el código de otra persona lleva mucho tiempo, en la mayoría de los casos, tanto como escribir su propio código desde cero. Modificar el código de otra persona e intentar mejorarlo, como lo alienta la filosofía GNU, es casi tan lento como desarrollar su propio clon de dicho programa con la funcionalidad que le gustaría agregar.
3. Tan pronto como 2 o más personas tengan que colaborar para desarrollar un programa más grande, esto crea muchos problemas de toma de decisiones que nunca surgirían en un proyecto de desarrollador único. El resultado es que, por ejemplo, si un grupo de 2 programadores colabora para un proyecto que tomaría 10 años para que un solo hombre lo haga, no lo harán en 5 años, sino probablemente en 8.
4. Si las personas que colaboran para el mismo proyecto se reúnen únicamente en Internet, es fácil que un miembro del proyecto desaparezca repentinamente (ya sea porque perdió interés o porque físicamente ya no puede estar en Internet), lo que hace que la colaboración sea incluso Más fuerte

Entonces, si bien entiendo perfectamente cómo se pueden desarrollar programas simples con la mentalidad de GNU, no veo absolutamente cómo son posibles programas tan grandes como GNU / Linux o gcc en este modelo. gcc tiene alrededor de 7 millones de líneas de código. Sé que las líneas de código no significan mucho, ya que en una etapa posterior de un proyecto, el programador más productivo es el que realmente eliminará las líneas de código (simplificando y / u optimizando el proyecto), pero esto da una visión general de lo masivo que es un proyecto gcc es.

Entonces, en teoría, cualquiera puede modificar libremente gcc durante su tiempo libre, ¿pero en la práctica? Fue desarrollado por personas muy profesionales como un trabajo, no como un hobby. Cualquiera que haga un compilador como pasatiempo eventualmente se dará por vencido ya que el costo / beneficio no vale la pena:

• El desarrollo de un gran programa es un gran proyecto a largo plazo, prefieren utilizar su tiempo libre para realizar otras actividades que sean más gratificantes o más agradables a corto plazo.
• Si desarrollaran un programa grande de todos modos, preferirían hacerlo para una compañía que les pagaría que hacerlo gratis

Para que la gente se interese en desarrollar un programa como GNU / Linux, gcc u Open Office a largo plazo, debería ser gratificante. Entonces mi pregunta es: ¿por qué hay personas que contribuyen al gran proyecto GNU, si no reciben un salario por ello?

Me gustaría comenzar diciendo que no soy programador y que nunca he contribuido a ningún proyecto de código abierto. Sin embargo, he estado interesado en el código abierto durante mucho tiempo y creo que entiendo los conceptos generales del código abierto y cómo funciona.

Para comenzar, me gustaría decir que el código abierto no significa que no se pueda ganar dinero con el software. Simplemente significa que el código debe estar disponible públicamente. Empresas como Red Hat y Canonical ganan dinero no vendiendo el software, sino vendiendo su experiencia. Si no quiero que mi empresa ejecute un servidor Linux, puedo obtener el software de forma gratuita. Pero necesito que alguien lo instale, lo configure y brinde soporte. Aquí es donde entra un especialista, por ejemplo, Red Hat y gana dinero. Para la empresa tiene sentido, porque contratar a su propio especialista probablemente sería mucho más costoso. Esto también les da a estas empresas un incentivo para contribuir con el código. Quieren que su producto sea bueno para que la gente lo use y por sus servicios.

Pero hablemos de sus puntos sobre la escalabilidad.

1. Lo bueno del código abierto es que no tiene que desarrollar todo desde cero. Un sistema operativo como Ubuntu no ha sido creado por una sola persona. En cambio, mucha gente ha contribuido a diferentes partes del sistema (de hecho, creo que sería difícil encontrar una persona con todas las habilidades para hacer un sistema operativo efectivo). Por ejemplo, la gente de Ubuntu no desarrolla el kernel de Linux. Solo usan uno desarrollado por otros. Entonces, lo que era sin código abierto probablemente imposible, ahora es posible, porque puedes aprovechar el trabajo de otras personas.

2. Leer y comprender a otros codifica no más tiempo que escribir el tuyo. Al menos no en muchos casos. Más allá de eso, no tiene que entender todo el código que usa. Si quiero escribir un programa para Linux, no tengo que entender cómo funcionan en detalle todas las partes de ese programa. Solo tengo que saber lo que hacen. Entonces puedo tomar estas partes y juntarlas con otras partes para crear mi programa. O puedo tomar un programa existente y modificarlo para mis necesidades.

3. herramientas como git y github hacen que sea increíblemente fácil colaborar. Simplemente obtienes el código y haces modificaciones. Luego los envía a la persona a cargo del proyecto. Si es bueno, será aceptado.

4. la gente entra y sale de proyectos todo el tiempo. Pero si el proyecto es popular, lo suficiente estará trabajando en ello.

Aquí hay algunas razones por las cuales el código abierto funciona.

1. Creo que la razón principal por la que el software de código abierto se ha vuelto tan bueno es porque la gran cantidad de personas que trabajan en un proyecto asegura un nivel de experiencia que es difícil de archivar en un pequeño equipo de desarrolladores. Si bien puede parecer extraño, este solo hecho parece superar todos los problemas negativos que pueden surgir en el código abierto.

2. En programación comercial, el proyecto muere con la firma. Digamos que por algún software de una compañía que luego cierra. Luego está jodido, ya que no recibirá actualizaciones y correcciones de errores, y necesitará un nuevo software para mantenerse al día. Con el código abierto, puede encontrar otra empresa que lo respalde o lo desarrolle usted mismo.

Si todavía estás interesado, te sugiero que leas La Catedral y el Bazar.

El desarrollo de software de código abierto se realiza por diversas razones, pero es un malentendido común que lo hagan principalmente aficionados o profesionales, pero como un proyecto paralelo. Estoy respondiendo esta pregunta para código abierto en general, no para software con licencia GNU en particular. Pero mi respuesta es inclusiva.

Digamos que soy un desarrollador de software (lo soy) y estoy trabajando en un proyecto de software complejo (lo soy). La buena arquitectura divide un problema en partes independientes y, a medida que avanza el desarrollo, los desarrolladores a menudo reconocerán que algunas de las piezas que necesitan son comunes a muchos problemas. Aquí hay algunos caminos típicos hacia adelante:

1. Desarrollan esa pieza ellos mismos y se convierte en propiedad de la empresa. O compran una solución de código cerrado de otra compañía.
2. Encuentran un proyecto de código abierto que resuelve este problema y es perfecto y la licencia es adecuada. Simplemente lo incorporan a su proyecto, que puede o no ser de código abierto dependiendo de la licencia y de cómo se use. No contribuyen de nuevo al proyecto.
3. Encuentran un proyecto de código abierto que casi resuelve este problema pero tiene defectos o deficiencias. Lo mejoran y pueden contribuir con esas mejoras al proyecto base.
4. No encuentran nada que les guste lo suficiente, por lo que comienzan su propio proyecto y deciden abrirlo.

Las ventajas de 2-4 son que más personas terminan contribuyendo tanto al diseño como al código del proyecto, y entra en una especie de ecosistema donde las ideas fuertes sobreviven (por procreación, si lo desea) y las débiles no. La corrección de errores y la adición de funciones se convierten en esfuerzos de la comunidad. En los escenarios # 2 y 3, los desarrolladores que adoptan el proyecto se benefician de los principios de ingeniería de sonido y el código maduro. 3 y 4 son correlativos. En el escenario # 4, los desarrolladores se benefician cuando otras personas adoptan y mejoran el código y lo devuelven (# 3). Es ventajoso contribuir de nuevo al proyecto para que sus mejoras se cimenten a medida que otras soluciones y mejoras se sumen a ellas, de las que continúa beneficiándose. En mi experiencia, todos estos escenarios son comunes.

En mi proyecto de software actual, soy uno de los 12 desarrolladores y he trabajado en un sistema durante aproximadamente dos años. ¡Hemos incorporado alrededor de 5,000 proyectos de código abierto! Hemos generado solo unos pocos proyectos FOSS nuevos, y contribuido de vuelta a quizás media docena. No somos ciudadanos particularmente buenos en este caso (otras compañías son mucho mejores), pero esto muestra la magnitud de cómo funciona todo esto. Incluso en proyectos pequeños, las contribuciones de código abierto pueden ser fácilmente decenas o cientos. Si no utilizáramos ningún software de código abierto, los costos de desarrollo se dispararían en un factor de 100-10,000.

La escalabilidad ocurre debido a la modularidad del diseño y también a través de este tipo de proceso de supervivencia del más apto donde el código puede ser refactorizado, bifurcado, etc. La supervivencia suele ser mejor que las alternativas patentadas porque incluso si el código ya no se mantiene, está disponible y otras personas que encuentran valor en él pueden mantener su propio tenedor. Las empresas van y vienen y los empleados son contratados y renuncian aún más rápido. Si agrega una dependencia de software para la que no tiene el código fuente o solo tiene que mantener un pequeño equipo interno, ha incurrido en un riesgo considerable. Grandes proyectos como el kernel de Linux, gcc, Android y otros a menudo tienen una gran cantidad de compañías que contribuyen activamente.

No es cierto que sea más fácil escribir un código correcto y correcto que leerlo (en la mayoría de los casos). Tampoco tiene que leer todo el software que está utilizando, incluso si está realizando modificaciones. Tienes que sumergirte profundamente en secciones y leer mucho, pero no todo. Podría decir más aquí sobre las pruebas unitarias, pero lo omitiré por brevedad.

La mayoría del software de código abierto no es desarrollado por personas en su tiempo libre. La práctica es tan fenomenalmente beneficiosa que funciona sin un mercado optimizador. Personalmente sospecho que algún tipo de enfoque impulsado por el mercado sería de gran ayuda, pero no sé cómo podría ser ese enfoque. La gente argumenta que hay un mercado donde la reputación es la moneda, pero no creo que sea un modelo exacto. Una moneda en el trabajo es el tiempo que lleva adoptar una nueva pieza de software. Desea encontrar y usar algo que sea activo, simple, que tenga buena documentación, etc. Entonces, como un comprador, está buscando el producto de mejor calidad por la menor cantidad de tiempo invertido.