Descubrí la Ley de Linus en el primer curso que tomé sobre cómo editar Wikipedia. Alguien hizo la tradicional pregunta sobre por qué cualquiera podía editar la enciclopedia – incluso, sin necesidad de registrarse como usuario, sino de forma anónima. La respuesta fue maravillosa: porque a mayor cantidad de ojos, mucho más obvios son los errores.
Lo que mi interlocutor quería explicar es que las entradas de la enciclopedia, a pesar de los vandalismos o ediciones bajo propósito, tienden a mantener un cierto estándar gracias a que la comunidad está atenta a los cambios y a que cualquier persona puede corregirlos. Claro, en la práctica, no cualquier persona se anima a editar, pero eso es otro tema – y un desafío grande para el proyecto de conocimiento libre.
Pero, ¿puede la Ley de Linus aplicarse a otros ámbitos? Sí. Una enseñanza básica del código abierto puede tener implicaciones positivas importantes si se aplica como filosofía de trabajo. No importa en qué te desempeñes: te aseguro que este precepto te será muy útil si lo empleas en tu vida cotidiana.
Entendiendo la Ley de Linus
En realidad (y según la misma Wikipedia), la frase que dijo Linus Torvalds fue:
Dado un número suficientemente elevado de ojos, todos los errores se convierten en obvios
Básicamente, el enunciado de Torvald refleja la esencia misma detrás del código abierto: la colaboración para la resolución de problemas. Esa es la explicación detrás de la supervivencia de muchos proyectos de código abierto y/o software libre, en los que una comunidad está en escrutinio constante de modo que los errores «saltan» a la vista.
A mí me gusta explicarlo con un salón de clases. Imagina un aula con 5 estudiantes; el profesor escribe en la pizarra: Moisés metió a los animales en el harca. Digamos que en el aula hay 5 alumnos; quizá alguno se percate que «arca» se escribe sin hache y corrija al profesor. Ahora imaginemos que en el aula hay 10, 20, 50 estudiantes. Entre más ojos, mayor la probabilidad de que ese error no pase desapercibido.
Por supuesto, aquí estoy simplificando mucho. Esto no quiere decir que si el aula tiene 500 alumnos, la clase se vaya sin errores. Quiere decir que si hay más alumnos atentos, es más probable que la equivocación se note. Cada uno tiene un bagaje de conocimientos diferente, así que cada uno puede notar cosas diferentes. Por ejemplo, ¿alguno de ustedes notó a la primera que la frase está equivocada? No fue Moisés quien metió a los animales al arca: fue Noé.
En el desarrollo de proyectos de código abierto y/o software libre, se asume que los errores serán evidentes entre más personas estén mirando. Es la razón para liberar el código en repositorios abiertos: permite que más gente, con diferentes herramientas y preparación, no sólo detecte problemas, sino que también sea capaz de corregirlos.
¿Cómo lo puedo adoptar en tres pasos?
1. Abre
Sin la transparencia, es imposible trabajar bajo este paradigma. Así como se libera el código de un proyecto, abre tu trabajo en la medida de tus posibilidades. Por ejemplo, si estás escribiendo un documento, compártelo con gente afin a tu área de trabajo o personas en cuya capacidad confíes. Permite que miren lo que estás haciendo y que lo retroalimenten.
Yo sé que a muchos nos les atrae la atención de un trabajo abierto a cierto público, pero es una forma de mejorar las cosas. Puedes ser un profesor que abra el diseño de su syllabus a otros colegas (o incluso, alumnos) o un escritor que comparta los avances de su novela. Incluso puedes abrir el flujo de trabajo: aquí en Betazeta usamos Trello y cada persona que forma parte de los sitios puede ver de qué va a escribir su colega y dejarle comentarios.
La opacidad es enemiga de la eficiencia. Piensa en un gobierno opaco en el que no tienes acceso a información pública básica (como saber en qué se gasta el presupuesto). Piensa en una empresa donde nadie sabe qué hace el otro departamento; piensa –y acá me pongo un poquito stallmaniano, nada más tantito– en un software o hardware que no sabes cómo funciona, cómo se repara o cómo se modifica. La apertura es positiva.
2. Revisa
Si alguien se ha animado a compartir su trabajo contigo, tómate un poco de tiempo en revisarlo y darle retroalimentación. No es algo difícil: aquí lo vemos todos los días, con cientos de comentarios que nos ponen en nuestros artículos (y de nuevo, hablemos de Linus, ustedes son los ojos que notan nuestros errores).
Notar la equivocación ya es la mitad del camino. Es más, hasta suena como algo divertido: cazar errores, hallar puntos débiles, encontrar fallos. Pero lo importante no es decir ¡hey, tú, tu trabajo apesta!, sino de verdad ser puntual y explícito: ¡hey, tú, tu artículo apesta porque encontré 3 faltas de ortografía y 8 errores de sintaxis acá, acá y acá!
Para eso, hay que estar abierto a recibir críticas; pero si logras convertir esas observaciones en soluciones, habrás hallado una metodología de trabajo que te ayudará a ser más productivo en tus labores. Pero, como siempre, el último escalón es el más alto.
3. Optimiza
¿Recuerdan la anécdota inicial sobre Wikipedia? Bueno, supongamos que encontramos un error grave en un artículo, ¿qué hacemos? Un buen porcentaje va a reírse del error en redes sociales; otro porcentaje (más pequeño) le dirá a algún wikipedista que edite y una porción diminuta hará clic en Editar y solucionará el problema.
Pregunta: ¿cuál de los tres quieres ser para hacer óptimo tu trabajo?
La razón del éxito de muchos proyectos de código abierto es que alguien se arremangó y decidió hacer algo. Las primeras dos condiciones que te he contado son de mucha ayuda, pero ésta es vital. Puedes tener un proyecto abierto a colaboración, recibir mucha retroalimentación, pero si al final no modificas, todo se queda ahí. Es como si el niño del aula le grita al maestro que la falta de ortografía está ahí, evidente, y el profesor se encoge de hombros. ¿Creen que ese chico volverá a marcarle un error? Probablemente no.
La Ley de Linus es una lección interesante como filosofía de trabajo porque enseña que no debemos temerle a los ambientes de colaboración; que podemos convertirlos en algo constructivo y que descentralizar es positivo para todos. A mí parecer, es una enseñanza del desarrollo abierto que puede incrementar tu calidad mediante el trabajo colectivo en vez del mero esfuerzo individual.
Fuente: fayerwayer.com
