Estos son los siete consejos para programadores open source publicados por el creador de SumatraPDF en el 15º aniversario de su app

Krysztof Kowalczyk es programador: ha escrito varios libros de programación que están accesibles en formato web y, sobre todo, es conocido por haber creado y seguir desarrollando uno de los lectores de PDF más populares después de Adobe Acrobat: SumatraPDF.

Y da la casualidad de que SumatraPDF acaba de cumplir 15 años desde su primer lanzamiento, por lo que Kowalczyk ha decidido escribir un extenso post en el que hace dos cosas: repasar datos curiosos sobre su lector de PDFs… y lanzar una serie de utilísimos consejos para el resto de programadores que trabajan con código abierto.

Entre las curiosidades, cabe destacar el hecho de que SumatraPDF es un software que consta de 127.000 líneas de código, escrito mayoritariamente por dos personas. Que nació como consecuencia de que Palm le encargara crear un lector de PDFs para Foleo, una minicomputadora portátil como ARM y Linux que nunca llegó a salir a la luz.

Pero, ¿qué ha aprendido en la década y media que ha pasado programándolo?

Es mi proyecto y me lo codifico como quiero

Kowalczyk afirma que uno de los grandes atractivos de trabajar en código por el que no te pagan por escribir es que nadie puede decirte qué hacer o cómo hacerlo. Nada de codificar a gusto de otros:

"Mi código no pasaría una revisión de código en Google y no porque sea malo, sino porque a menudo es poco ortodoxo. Fuera del dogma aceptado".

"Implementé un sistema de interfaz de usuario inspirado en CSS: no es genial, pero es mío. Y planeo reemplazarlo con uno diferente. Porque puedo".

No comiences un proyecto open source pensando en ganar dinero…

Rara vez podrás tener libertad para hacer lo que quieras y ganar dinero por ello, así que elige lo más importante para ti, explica. Afirma ganar poco más de 100 dólares al mes gracias a Patreon y a las donaciones vía PayPal, pero poco más:

"El código abierto no es un buen modelo de negocio. Si quieres ganar dinero, haz literalmente cualquier otra cosa: intenta vender software, sé consultor, desarrolla un SAAS y cobrar mensualmente por ello, roba un banco…".

…pero trata tu proyecto open source como si fuera software comercial

Lo anterior no está reñido con su convicción de que si deseas que tu software 'open source' sea lo más exitoso posible, debes tratarlo como si fuera un producto comercial. Pero, ¿qué significa eso en la práctica?

"Desde el primer día creé un sitio web para la aplicación. Tenía capturas de pantalla, tenía documentación, era fácil de descargar e instalar. Por supuesto, un alma amable en Reddit lo llamó "un sitio web hecho por un niño de 6 años". La lección aquí es doble: 1) ignorar a haters y gilip*llas, 2) un sitio web construido por un niño de 6 años es mejor que ningún sitio web. No tiene que ser bonito, tiene que ser funcional".

"Todo lo que es una buena idea para promover el software comercial también es una buena idea para el proyecto de código abierto".

Por eso también recomienda emprender otras medidas, como la obtención de usuarios tempranos, descubrir qué funcionalidades quieren, e implementar un montón de éstas antes de saber si a alguien le importa lo que estamos haciendo.

Ser pequeño y rápido siempre será una ventaja

Kowalczyk afirma que nunca llegará el momento en el que los usuarios pidan aplicaciones "hinchadas y lentas" por lo que "ser pequeño y rápido siempre será una ventaja". Y SumatraPDF, con su instalador de menos de 10 MB y su inicio cuasi instantáneo, cumple de sobra con tal objetivo.

"La simplicidad vende […] eso lo aprendí de la historia de Mozilla Firefox. Antes de Firefox existía Netscape Navigator. Era una bestia de una aplicación, que combinaba el navegador web con el cliente de correo electrónico. El más sencillo Firefox se terminó comiendo por completo a Navigator".

"Desde el principio mi objetivo fue mantener la interfaz de usuario de SumatraPDF lo más sencilla posible, como una aplicación 80/20: 80% de la funcionalidad con el 20% de la interfaz de usuario".

Pero, ¿cómo logra mantener así de ligera su aplicación (además de rechazando constantemente las peticiones de añadir nuevas funcionalidades o nuevos iconos a la interfaz)?

"Evito las abstracciones innecesarias. […] Podría usar envoltorios como Qt, WxWindows o Gtk; son más fáciles de usar, pero causan un hinchamiento desmesurado [de la app]".

"No tengo miedo de escribir mi propia implementación de las cosas. […] Digamos que necesito hacer una solicitud de red: tengo la opción de incluir una biblioteca monstruosa Como curl o de escribir 300 líneas de código usando las API de Win32. Yo opté por escribir las 300 líneas de código".

La multiplataforma está sobrevalorada

Kowalczyk califica SumatraPDF como una aplicación "descaradamente sólo-para-Windows". Las peticiones de soporte a otras plataformas son frecuentes, pero él las descarta de plano. Y dejando de lado la falta de tiempo, enarbola otro argumento más:

"Creo que una excelente aplicación para una plataforma puede llegar a ser más popular que una aplicación mediocre para tres plataformas".

'Be water, my friend'

Kowalczyk cita al gran Bruce Lee y nos recomienda 'ser agua', "adaptarnos a los cambios del mundo". ¿Qué tipo de cambios?

• De repositorio: "Empecé con Sourceforge, cambié a code.google.com y luego a github.com".
• De CMS para el foro: "He cambiado el software del foro ya tres veces".
• De Windows: Antes sólo existía SumatraPDF para 32 bits y ahora, aunque sigue existiendo, hace hincapié en la de 64 bits; al mismo tiempo, Windows XP pasó de ser la versión más usada por los usuarios de su programa a dejar de ser compatible con éste.

"SumatraPDF no fue la primera aplicación de lector de PDF jamás escrita… pero la mayoría de los lectores de PDF no se convierten en lectores multiformato. [Era] una idea obvia, pero me llevó 5 años darme cuenta. […] Creo que ser multiformato ayudó a SumatraPDF a ser popular".

Haz código de calidad

Como decía más arriba, que el código no sea ortodoxo no significa que tenga que ser de baja calidad, pero

"¿cómo mantener un código de alta calidad mientras trabajas en su mayor parte en solitario, sin que nadie haga revisiones de código, sin un equipo de control de calidad?".

Kowalczyk propone varias opciones: "usa mucho tu propia aplicación… prueba el código tú mismo"; apostar por los informes automatizados de fallos, las pruebas de esfuerzo, las unitarias y los análisis de código estático:

"Pon al máximo el nivel de advertencias en el compilador de C++, convierte las advertencias en errores, activa la opción /analyze de Visual Studio, etc.".

Imagen | OpenSource.com