La semana pasada, Linus Torvalds continuó con una extensa entrevista por correo electrónico con Jeremy Andrews, socio fundador y director ejecutivo de Tag1.

En la primera parte de la entrevista en abril, Torvalds habló de todo, desde los chips ARM64 de Apple y los controladores Rust, hasta su propio entorno de trabajo desde casa basado en Fedora y sus pensamientos sobre los primeros días de Linux. Pero la segunda parte ofrece una visión más profunda de cómo piensa Torvalds, una visión personal de lo que compartiría con otros mantenedores de proyectos y algunas ideas sobre cómo conseguir que las empresas ayuden a hacer crecer el negocio.

Linus reveló cómo procedió cuando comenzó el proyecto:

“Todavía recuerdo los primeros días, cuando la gente me enviaba arreglos, y realmente no los aplicaba como arreglos, pero los leía, que entendía lo que la gente quería hacer y que lo hice yo mismo. Porque así comencé el proyecto, y así me sentí más cómodo y que conocía mejor el código ”. Linus también explicó que era importante aprender a delegar: “Dejé de hacerlo bastante rápido, porque básicamente soy un vago. Me volví muy bueno leyendo los parches y descubriendo lo que estaban haciendo, y luego los apliqué ”.

Linus también se esforzó por permanecer imparcial a medida que Linux crecía y se volvía más exitoso:

“Yo muy conscientemente no quería trabajar para una empresa de Linux, por ejemplo, mantuve Linux durante la primera década sin que fuera mi trabajo. Esto no es porque crea que los intereses comerciales son malos, sino porque quería asegurarme de que la gente me viera como una parte neutral y nunca me sentí como «la competencia». «

Si bien el código abierto ha tenido un gran éxito, muchos de los usuarios más grandes, como las empresas, hacen poco o nada para apoyar o contribuir a los proyectos de código abierto de los que dependen.

Continúa escribiendo:

“Y muchas de las grandes empresas de tecnología que utilizan el kernel terminan participando activamente en el proceso de desarrollo. A veces terminan haciendo mucho trabajo interno y no son muy buenos empujando las cosas hacia atrás (no nombraré nombres, y algunos de ellos realmente están tratando de hacerlo mejor), pero en realidad es muy alentador ver a las grandes empresas que están involucradas de manera muy abierta en el desarrollo básico upstream y son miembros importantes de la comunidad ”.

Cuando se le preguntó si el código abierto es sostenible o no, Linus respondió:

“Sí. Personalmente, estoy 100% convencido de que no solo el código abierto es sostenible, sino que para cuestiones técnicas complejas realmente necesita el código abierto solo porque el espacio del problema termina siendo demasiado complejo para ser manejado por una sola empresa. Incluso una empresa de tecnología grande y competente ”.

Clave para el éxito de los encargados del mantenimiento de proyectos de código abierto: «estar ahí TODO EL TIEMPO» y «estar abierto»

Cuando Andrews quiso saber qué hace que un proyecto de código abierto sea exitoso, Linus admitió:

“Realmente no sé cuál es la clave del éxito. Sí, Linux ha tenido mucho éxito y está claro que Git también ha comenzado con el pie derecho, pero todavía es muy difícil atribuirlo a una causa más profunda. ¿Quizás tuve suerte? ¿O fue porque de todas estas personas que necesitaban estos proyectos, yo fui el que se puso de pie, hizo el trabajo y comencé el proyecto? «

Pero Linus finalmente explicar» algunos puntos prácticos y con los pies en la tierra que yo personalmente considero importante si usted es un fabricante de software de código abierto «. Recomienda que una persona a cargo de un proyecto de código abierto esté «presente» todo el tiempo.

“Tienes que quedarte, tienes que estar ahí para los otros desarrolladores, y tienes que estar ahí TODO EL TIEMPO. Te encontrarás con problemas técnicos y será frustrante. Trabajará con personas que pueden tener ideas muy diferentes sobre cómo resolver estos problemas técnicos. Y los problemas técnicos son la parte más fácil, porque generalmente tienen soluciones técnicas, y a menudo se puede decir de manera bastante objetiva «esto es mejor / más rápido / más fácil / lo que sea» «.

La otra clave que explicó Linus es estar «abierto», «estar abierto a las soluciones de otras personas y no tener esta idea muy clara e inflexible de cómo se deben hacer las cosas». Pero Linus denuncia una de las formas de ser abierto:

“Es realmente fácil crear una especie de ‘camarilla’ de personas, donde tienes una camarilla interna que discute las cosas en privado, y luego realmente solo ves el resultado final (o marginal trabajar) a plena luz del día, porque todas las cosas importantes han sucedido dentro de una empresa o dentro de un grupo central de personas, y a los externos les resulta difícil penetrar estos clics y, a menudo, incluso les cuesta ver lo que está sucediendo en ese grupo principal porque era tan privado y exclusivo ”.

“Esta es una de las razones por las que realmente me gustan las listas de correo abiertas. No es una lista de «invitaciones». Ni siquiera tienes que registrarte para participar. Está realmente abierto. Y prácticamente todas las discusiones sobre desarrollo deberían estar allí ”.

Hablando de otras habilidades específicas necesarias para proyectos exitosos de código abierto, Linus explicó su experiencia. Según él, “no es el resultado de planificar y leer manuales de gestión, etc. La mayoría de las cosas sucedieron solas, y la estructura que tenemos hoy no proviene de un organigrama escrito, sino de personas que acaban de «encontrar su lugar». Como ya se mencionó anteriormente, Linus recomienda la delegación de tareas. También mencionó las habilidades de comunicación como «muy importantes».

Fuente: https://www.tag1consulting.com