Lo que los desarrolladores pueden aprender de Anonymous

Cuando he tenido la oportunidad de liderar un proyecto de código abierto, siempre he preferido ejecutarlo bajo un esquema de libre albedrío y de pronta ejecución al que he bautizado como "do-ocracy", el cual significa que yo puedo dar mi opinión pero los desarrolladores son libres de ignorarla. En otras palabras, los desarrolladores de hoy en día deberían tener la capacidad de tomar decisiones de bajo impacto ellos mismos.

Si uno piensa en ello, el colectivo hacktivista Anonymous es tal vez una de las organizaciones más democráticas en el sentido de permitir la acción de sus miembros. Más allá de la posición personal que cada quien tenga sobre las tácticas y políticas del grupo, creo que los desarrolladores y las compañías de desarrollo tienen algo que aprender de estos hackers.

Como líder de un proyecto de código abierto, puedo revocar el acceso al comité a cualquiera que no se comporte adecuadamente, pero la membresía en Anonymous es libre. Ciertamente, realizar cualquier cosa bajo el nombre de Anonymous sin el consentimiento o aprobación de al menos una minoría será un error táctico, pero el colectivo no cuenta con derechos de marca para protegerse legalmente, simplemente tienen una visión y metas generales. Y los miembros realizan acciones con base en esta misión, con bastantes éxitos hast el momento -debidos, en parte, a la ausencia de un control central.

Al comparar esto con el nivel de control en varias organizaciones desarrolladoras, vemos que parte de ese control es necesario, pero frecuentemente se lleva a los extremos. Si contrata grandes desarrolladores, establezca objetivos generales para diversos componentes del proyecto y mida los resultados; probablemente no tenga que ejercer mucho control para alcanzar los requerimientos.

¿Es posible aplicar esta democracia en contextos ajenos al código abierto y el hacktivismo? No en el mismo nivel que lo hace Anonymous, pero en cantidades moderadas podría mejorar la calidad general del software y el trabajo que desarrollamos.

Reglas de cultura y visión

Los miembros de Anonymous eligen objetivos y llevan a cabo acciones con base en la visión general y la cultura del grupo. Ya sea que estén en una democracia o no, la visión es lo principal.

Hace algunos años trabajé para una compañía de equipo de redes. Probablemente fue uno de los peores trabajos que he tenido, metido en una fila de cubículos color beige con contornos de un verde enfermizo. No solamente se me pidió escribir lo que aprendí en mis clases de Java en forma de cápsulas, con pocas filas y espacios en blanco al mínimo, sino que diariamente teníamos horas de llamadas de conferencia con el equipo de New Jersey. Nuestras computadoras eran antiguas y la conexión shell, muy lenta. Pero la "visión" era tratar de mantenernos al día con lo que Cisco estaba haciendo.

Internamente, el proyecto era un éxito, pero para mí era un claro fracaso. Me habría sorprendido que la empresa lograra retener a sus clientes y dudo mucho que se hiciera de nuevos. El sitio web era horriblemente confuso y poco atractivo, pero se suponía que debía ser un sitio B2B. La cultura de la empresa y su etéreo objetivo no hacían pareja con la necesidad de controlar los requerimientos predecibles.

Pero consideremos cómo trabaja Anonymous. Empezó con una visión general de ataques anarquistas contra centros de poder. Con el tiempo, se ha convertido específicamente en un "corrector de mal comportamiento" y ha conseguido captar la atención. No existe un plan a cinco años (que sea conocido). Algo sucede, un grupo de personas se unen -ya sea en un chat IRC o en otro medio- y colaboran a su propio modo. Aunque no haya un plan general, obtienen éxito táctico.

Por otro lado, la ausencia de un plan provoca que Anonymous se esclavice al ciclo de noticias. No digo que sus actividades a la altura de la Primavera Árabe no aporten nada, pero los objetivos estratégicos no se cumplieron -como ejemplo, el llamado constante para tirar la señal satelital del canal de TV de Gadhafi por parte de quienes luchaban por la libertad. Aquí es donde un plan les sería de ayuda. He visto muchas organizaciones funcionar sin un plan o visión compartidos. Pero aún no he visto un proyecto de software que sea exitoso sin ambas cosas.

El control tiene sus límites

Muchos gerentes creen que si no obtienen los resultados que buscan, simplemente tienen que presionar al equipo. Pero en mi experiencia como desarrollador que llegó a un cargo gerencial, puedo decirles que entre más presiono ese botón, menos eficiente resulta.

Considere los infortunios de nuestros hackers anti-héroes. En donde quiera que Anonymous tenga un nervio central, ahí será atacado, y ello ha conducido a arrestos. Los efectos han impactado negativamente al grupo.

También podemos ver esto en lo que se refiere a arquitectura del servidor. Aún hay plataformas de cluster que se gestionan a través de un servidor central -el punto débil desde Hadoop hasta WebSphere. Pero estamos viendo la evolución de estas arquitecturas más allá del control central. Esto resulta en circunstancias menos predecibles, pero más robustas a largo plazo.

La metáfora es transferible a las áreas de proyectos de software. Sí, hay que establecer expectativas y normas, y tomar en cuenta que la motivación puede tener un efecto positivo y evitar crisis. No estoy abogando por la anarquía. Pero el modelo de afiliación libre de Anonymous, una organización notoria por su caos interno, tiene más que enseñar de lo que cualquiera de nosotros quisiera admitir.

– IDG News / Infoworld US