Linux

A los niños de GitHub todavía no les importa el código abierto

A los ninos de GitHub todavia no les importa el

El código abierto nunca ha sido más generalizado, impulsando cambios tectónicos en los dispositivos móviles, la computación en la nube y los grandes datos. Sin embargo, el código abierto sigue siendo una ocurrencia tardía para la gran cantidad de codificadores que acuden en masa a GitHub, como muestran los nuevos datos.

GitHub ha hecho un esfuerzo significativo para que sus desarrolladores obtengan licencias de su software con cuidado, pero la mayoría de los desarrolladores se muestran desdeñosos. Esto crea problemas para aquellos que eligen implementar este software aparentemente sin licencia.

Pero en lugar de rehuir la gran cantidad de código publicado en GitHub, los usuarios potenciales del código de GitHub deben comenzar a solicitar permiso para el código. Esta puede ser la única forma de cambiar el movimiento aparentemente permanente a código completamente abierto.

Al principio fue Sourceforge

GitHub es un recién llegado al alojamiento de código fuente, pero se ha convertido rápidamente en el único repositorio confiable. Sourceforge fue el primer gran repositorio de código, seguido por Codehaus, CodePlex de Microsoft y Google Code, entre otros.

Si bien CodePlex todavía se está moviendo, Sourceforge se inclinó ante Google Code hace años. De hecho, parece que Google Code dominará el alojamiento de código durante mucho tiempo, hasta que GitHub se acelere. Recientemente, tanto Codehaus como Google Code se cerraron y GitHub los eliminó gradualmente.

No es que Google sea inocente.

Según Andrew Binstock, editor en jefe de Dr. Dobb’s Journal, Google Code alguna vez fue el favorito de los desarrolladores de la industria, pero los pasos en falso de Google lo hicieron vulnerable a los ataques de GitHub:

LEER  Makulu LinDoz demuestra que Linux puede imitar con éxito a Windows

«Cuando salí por primera vez, [Google Code] Es una meca para nuevos proyectos, sembrada por muchos proyectos de Googlers. Su interfaz de usuario es bastante de baja tecnología, pero es rápida y fácil de operar. Además, tiene muchas características que son particularmente atractivas para los programadores. Sin embargo, Google ha tardado en mejorar el sitio para reconocer las preferencias cambiantes de los desarrolladores. Y la empresa no ha actualizado su interfaz de usuario propietaria. Y no ayuda mucho con las solicitudes de los usuarios. Todos estos son errores críticos. «

GitHub pone a los desarrolladores en primer lugar, lo que podría decirse que es su «función principal». Al poner a los desarrolladores primero, me refiero a que GitHub pone el código primero más que cualquier otro repositorio de código, hay un excelente artículo de Wired que entra en gran detalle. En lugar de colocar a un desarrollador en una página de descripción general, GitHub empuja inmediatamente al desarrollador al código y luego facilita la bifurcación del código.

Pero uno de los peligros potenciales de esta simple experiencia es que la mayoría de los desarrolladores de GitHub continúan ignorando el código abierto.

a los niños no les importa

Como capturó el analista de Redmonk Donnie Berkholz, el cambio a licencias permisivas de código abierto ha estado en pleno apogeo durante años, pero GitHub ha llevado esta tendencia al siguiente nivel.O, como proclamó la lumbrera del software libre Glyn Moody, «la conclusión lógica de cambiar a licencias más ‘permisivas’ [is] Un hombre que lo permite todo. «

Eso es exactamente lo que muestran los datos de licencias de GitHub.

Hace dos años, GitHub publicó datos que muestran que los millones de proyectos que aloja optan por las típicas licencias de código abierto, o mejor dicho, la falta de ellas.

Neil McAllister descubrió que en 2013 solo el 14,9 % de los proyectos en GitHub tenían una licencia confirmada. Dos años después, las cosas han mejorado, pero no tan bien como Ben Balter de GitHub nos quiere hacer creer.

Como puede ver en el gráfico a continuación, la introducción de choosealicense.com y su selector de licencias en GitHub ayudó a revertir el declive a largo plazo de los repositorios con licencia (es decir, repositorios de código con licencias claramente identificadas). Pero lo que también se puede ver es un retroceso hacia la anarquía de licencias:

1678843447 523 A los ninos de GitHub todavia no les importa el

«Los resultados superaron incluso mis expectativas más altas para el código abierto», dice Balter. Si es así, es posible que deba aumentar sus expectativas.

Después de todo, el código sin licencia no es sin licencia. Todo el software, ya sea con licencia expresa o no, tiene derechos de autor. Así es como funciona la ley de derechos de autor.

Entonces, si todo este software «sin licencia» en realidad viene con una licencia, ¿cuáles son los derechos de todos los millones de desarrolladores que usan ese código? Aquí es donde radica el problema.

Balter continuó: «Los desarrolladores usan GitHub porque quieren compartir su código con el mundo, y los datos muestran que cuando las herramientas que usamos facilitan las cosas, los desarrolladores lo hacen. Cuando se les presentan opciones, eligen la licencia, y la otorgaron con mucha indulgencia. .»

Pero eso no es lo que dicen los datos. Los datos muestran que incluso con las opciones de licencia disponibles, la gran mayoría de los desarrolladores de GitHub no licenciarían su código bajo ninguna licencia específica, de código abierto o de otro tipo. Eso significa que GitHub sigue siendo un montón de software con licencias dudosas.

De todos modos, ¿deberías usarlo?

¿Importa? Si, absolutamente. Pero, ¿te impide a ti y a tu empresa usar el software GitHub? No, absolutamente no lo hace.

Después de todo, como señala Berkholz, «A medida que los proyectos crecen, tienden a solucionar cualquier problema de licencia, tal vez a medida que adquieren usuarios corporativos, desarrolladores profesionales, etc.» En otras palabras, el código más popular generalmente encuentra la forma de obtener licencias convencionales , porque suficientes personas se involucrarán para esperar un comportamiento de licencia general.

Pero hay otra opción, y es forzar un cambio. Los posibles contribuyentes o usuarios de proyectos de GitHub pueden y deben pedir a los creadores de código que elijan una licencia. Toma muy poco tiempo y le ahorra muchas molestias más adelante. (Si elige implementar una gran cantidad de software con licencia dudosa en su producto, intente realizar una revisión del código en la adquisición de la empresa. No es muy bueno).

Simplemente hacer una pregunta es suficiente para que la mayoría de los patrocinadores de proyectos los lleven a choosealicense.com. Es posible que no se den cuenta de la importancia de hacer esto hasta que se lo pidas.

Así que pregunte. Después de todo, también es su código, o podría serlo, con las licencias adecuadas.

LEER  Cómo configurar un servidor GitLab y alojar su propio repositorio Git

Deja una respuesta

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *

Botón volver arriba