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

Question

Me disculpo 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 del SE, por favor indíqueme.

En teoría, el software de GNU es desarrollado íntegramente por voluntarios en su tiempo libre, o por empresas que financian voluntariamente a los programadores para que desarrollen software de GNU (utilizando los ingresos de otro sector de su actividad).

Entiendo cómo puede funcionar perfectamente bien para un proyecto a pequeña escala que puede ser realizado en un par de fines de semana lluviosos por un solo individuo (digamos por ejemplo un juego de sudoku), porque después de todo la programación informática es un pasatiempo extremadamente divertido y gratificante, y no tengo ningún problema en ver a la gente desarrollando pequeños o medianos programas durante su tiempo libre y compartiéndolos con el mundo.

El problema es que esta escala es extremadamente pobre para los programas más grandes por las siguientes razones:

1. Por muy divertido que sea programar, a medida que el proyecto que hay que implementar se hace más grande, el tiempo que toma implementar la funcionalidad deseada crece extremadamente rápido. Un programa de mayor escala toma una increíble cantidad de tiempo para desarrollarse, por ejemplo podría fácilmente tomar 15 años de tiempo libre y vacaciones para que un individuo programe un sistema operativo, y para el momento en que su software sea liberado estará completamente obsoleto.
2. Como otras personas escriben programas de otra forma que la que tú habrías hecho, leer y entender el código de otra persona toma mucho de tiempo, en la mayoría de los casos tanto como escribir tu propio código desde cero. Modificar el código de otra persona y tratar de mejorarlo, como lo alienta la filosofía GNU, es casi tan consumidora de tiempo como desarrollar tu propio clon de dicho programa con la funcionalidad que te gustaría añadir.
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 un solo desarrollador. El resultado es que, por ejemplo, si un grupo de 2 programadores colaboran 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 en el mismo proyecto se reúnen únicamente en Internet, es fácil que un miembro del proyecto desaparezca repentinamente (ya sea porque perdió el interés o porque físicamente ya no puede estar en Internet), lo que hace que la colaboración sea aún más difícil.

Así que, aunque entiendo perfectamente cómo se pueden desarrollar programas simples con la mentalidad GNU, no veo cómo programas tan enormes como GNU/Linux o gcc son posibles 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 idea de cuán masivo es un proyecto gcc.

Así que, en teoría, cualquiera puede modificar libremente el GCC en su tiempo libre, pero en la práctica Fue desarrollado por gente muy profesional como un trabajo, no como un hobby. Cualquiera que haga un compilador como hobby eventualmente se dará por vencido ya que el costo/beneficio no vale la pena:

• El desarrollo de un gran programa es un proyecto tan grande a largo plazo, que prefieren utilizar su tiempo libre para tener otras actividades más gratificantes o más agradables a corto plazo.
• Si desarrollaran un gran programa de todas formas, preferirían hacerlo para una compañía que les pague 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. Así que mi pregunta es: ¿Por qué hay gente contribuyendo al gran proyecto GNU, si no reciben un salario por ello?

Answer 1

Me gustaría empezar diciendo que no soy programador y que nunca he contribuido a ningún proyecto de código abierto. Sin embargo, me interesa el código abierto desde hace mucho tiempo y creo que entiendo los conceptos generales del código abierto y cómo funciona.

Para empezar, me gustaría decir que el código abierto no significa que no puedas ganar dinero con el software. Sólo significa que el código tiene que estar disponible públicamente. Compañías como Red Hat y Canonical ganan dinero no vendiendo el software, sino vendiendo su experiencia. Si no quiero que mi compañía maneje un servidor Linux, puedo obtener el software gratis. Pero necesito a alguien que lo instale, lo configure y dé soporte. Aquí es donde los especialistas de, por ejemplo, Red Hat entran y ganan dinero. Para la compañía tiene sentido, porque contratar a su propio especialista sería probablemente mucho más caro. Esto también le da a estas compañías 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 tus puntos sobre la escalabilidad.

1. Lo bueno del código abierto es que no tienes que desarrollar todo desde cero. Un sistema operativo como Ubuntu no ha sido construido por una sola persona. En su lugar, 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 núcleo de Linux. Sólo usan uno desarrollado por otros. Así que lo que era imposible sin el código abierto, ahora es posible, porque se puede construir sobre el trabajo de otras personas.

2. Leer y comprender el código de los demás no lleva más tiempo que escribir el suyo propio. Al menos no en muchos casos. Más allá de eso, no tienes que entender todo el código que usas. Si quiero escribir un programa para Linux, no tengo que entender en detalle cómo funcionan todas las partes de ese programa. Sólo tengo que saber lo que hacen. Entonces puedo tomar estas partes y ponerlas juntas con otras partes para crear mi programa. O puedo tomar un programa existente y modificarlo para mis necesidades.

3. herramientas como git y github hace que sea increíblemente fácil colaborar. Sólo tienes que conseguir el código y hacer modificaciones. Luego las presentas a la persona a cargo del proyecto. Si es bueno, será aceptado.

4. la gente entra y sale de los proyectos todo el tiempo. Pero si el proyecto es popular, basta con trabajar en él.

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

1. Creo que la principal razón por la que el software de código abierto se ha vuelto tan bueno es que el gran número 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. Aunque pueda parecer extraño, este único hecho, parece superar todos los problemas negativos que pueden surgir en el código abierto.

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

Si todavía está interesado, le sugiero que lea La Catedral y el Bazar

Answer 2

El desarrollo de software de código abierto se hace por diversas razones, pero es un malentendido común que se hace principalmente por aficionados o profesionalmente, pero como un proyecto paralelo. Estoy respondiendo a esta pregunta para el código abierto en general, no para el 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 piezas independientes, y a medida que el desarrollo avanza, los desarrolladores a menudo reconocen que alguna pieza que necesitan es una que es común a muchos problemas. Aquí hay algunos caminos típicos para avanzar:

1. Ellos mismos desarrollan esa pieza y se convierte en propiedad de la compañía. O compran una solución de fuente cerrada de otra compañía.
2. Encuentran un proyecto de código abierto que resuelve este problema y es un ajuste 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 utilice. No contribuyen al proyecto.
3. Encuentran un proyecto de código abierto que casi resuelve este problema pero que tiene defectos o deficiencias. Lo mejoran y pueden contribuir con esas mejoras al proyecto base.
4. No encuentran nada que les guste lo suficiente, así que empiezan su propio proyecto y deciden abrirlo.

Las ventajas de 2-4 son que más gente termina 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 se quiere) y las débiles no. La corrección de errores y la adición de características se convierten en esfuerzos comunitarios. En los escenarios 2 y 3, los desarrolladores que adoptan el proyecto se benefician de principios de ingeniería sólidos y 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 cimienten como otros arreglos y mejoras van encima de ellos, de los cuales usted continúa beneficiándose. En mi experiencia, todos estos escenarios son comunes.

En mi actual proyecto de software, soy uno de los 12 desarrolladores y he trabajado en un sistema durante unos dos años. Hemos incorporado alrededor de 5.000 proyectos de código abierto! Hemos generado sólo unos pocos proyectos nuevos de software libre, y hemos contribuido a quizás media docena. No somos particularmente buenos ciudadanos en este caso (otras compañías son mucho mejores), pero esto le muestra la gran escala de cómo funciona todo esto. Incluso en los proyectos pequeños, las contribuciones de código abierto pueden ser de docenas o cientos. Si no usáramos ningún software de código abierto, los costos de desarrollo se dispararían por un factor de 100 a 10.000.

La escalabilidad se produce gracias a la modularidad del diseño y también a este tipo de proceso de supervivencia en el que el código puede ser refactorizado, bifurcado, etc. La supervivencia es generalmente mejor que las alternativas propietarias porque incluso si el código ya no se mantiene, está ahí fuera y otras personas que encuentran valor en él pueden mantener su propia bifurcación. Las empresas van y vienen y los empleados son contratados y renuncian aún más rápido. Si se añade una dependencia de software para la que no se tiene el código fuente o sólo se tiene un pequeño equipo interno para mantenerlo, se ha incurrido en un riesgo sustancial. Los grandes proyectos como el núcleo de Linux, gcc, Android y otros a menudo tienen un gran número de empresas que contribuyen activamente.

No es cierto que sea más fácil escribir un código bueno y correcto que leerlo (en la mayoría de los casos). Tampoco tienes que leer todo el software que estás usando aunque estés haciendo modificaciones. Tienes que sumergirte profundamente en secciones de él y leer mucho, pero no todo. Podría decir más aquí sobre las pruebas de unidad, pero omitiré eso por brevedad.

La mayoría de los programas de código abierto no son desarrollados 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 orientado al mercado ayudaría mucho, 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 funcionamiento es el tiempo que se tarda en adoptar una nueva pieza de software. Quieres encontrar y usar algo que sea activo, simple, que tenga buena documentación, etc. Así que, como un comprador, buscas el producto de mejor calidad por la menor cantidad de tiempo invertido.