Mejor sí, pero… ¿para quién?

Tantos años en la sala de máquinas, trabajando en las tripas de la bestia, sin contacto directo con los usuarios finales. Como tantos otros técnicos, mi percepción del producto siempre ha sido “de puertas para dentro”. En esas condiciones, tomas decisiones de diseño e implementación basadas en tu propio criterio, y tu criterio es técnico. “Mejor” es más eficiente, “mejor” es más correcto y elegante, “mejor” es más ingenieril. En definitiva, te esfuerzas en hacer mejor software, pero no tienes ni idea de si estás haciendo mejor producto. Porque una mejor ejecución no implica más aceptación, y un producto es tan bueno como su penetración en el mercado atestigüe. Eso, amigos, es lo que habré sacado en claro de estos años al frente de una empresa de producto. El cliente manda, ya sabéis.

Esto, tan evidente y de sentido común para todo aquel que haya tratado de llevar un producto al mercado, no es tema baladí. Muchas veces el mercado tiene opiniones sobre lo que tu producto debería ser muy alejadas de la tuya propia, y eso es complicado de gestionar. Maldito orgullo. A Steve Jobs le funcionaba bien lo de saltarse esa máxima a la torera, al resto de los mortales suele precipitarlos al abismo. Un asunto espinoso, complejo y apasionante.

Los entresijos del llamado market fit me tienen por tanto muy interesado, y se ha estado desarrollando en los últimos días un episodio a mi parecer muy ilustrativo, que por peso del producto implicado es de especial interés. Me refiero a la muy en voga transición de Python 2 a Python 3 y al tremendo pifostio que se ha montado alrededor. Agárrense que vienen curvas.

Contextualizando

Empezando por el principio: Python, para los no techies de la sala. Python es un lenguaje de programación. Lleva dando guerra más de 20 años ya, y es una de las plataformas de desarrollo de software más usadas en el mundo. Goza de excelente salud, además, en los principales campos de desarrollo de aplicaciones. Es casi un estándar de facto en ciencias y estadística, uno de los principales lenguajes en uso en software de sistemas, tiene una importante presencia en la industria del videojuego y está entre los líderes en desarrollo web, la niña bonita del momento. Es top10 en cualquier ranking de popularidad (como TIOBE o LangPop) desde hace años. La lista de proyectos reseñables construidos sobre Python incluyen a Youtube, Dropbox, Spotify, Instagram, Pinterest, Reddit, o Quora. Ha sido durante mucho tiempo (hasta la aparición de Go) uno de los únicos tres lenguajes oficiales en Google junto a Java y C++. Os hacéis una idea.

Como suele darse con proyectos open source tan exitosos, el papel de la comunidad es muy importante. ¿Qué es la comunidad de un proyecto open source? Pues el conjunto de contribuidores y usuarios. Los contribuidores aportan código, utilidades, documentación, traducciones o soporte. Los usuarios, con su feedback y elección de tecnologías, votan y modelan el futuro del proyecto. Sin una comunidad, un proyecto open source no crece y no obtiene una masa crítica para ser relevante. Nadie escoge una tecnología que nadie usa y no está probada. Y es que un millón de ojos ven más que los pocos que puedan aportar los desarrolladores de la criatura. Python puede alardear de tener una inmensa y muy activa comunidad. Es, como decía, una de las claves de su éxito.

El detonante

Hasta aquí el asunto del market fit es más bien ejemplar, ¿no? Unos tipos (con Guido van Rossum a la cabeza) lanzan un producto al mercado con un tremendo éxito y consiguen una muy cómoda posición. Poco que objetar. Pero esos tipos son programadores, y viven en la sala de máquinas, y con el tiempo y el éxito se han distanciado del usuario final (ahora hay infraestructura para encargarse de eso), así que empiezan a valorar el producto (Python en su versión 2) exclusivamente desde su punto de vista. Y desde un punto de vista puramente ingenieril, el producto es mejorable…

¡Así que lo mejoran! Se ponen a trabajar, encerrados en su burbuja, en arreglar todos los problemas de base del lenguaje. ¿Problemas con la codificación de cadenas de texto? La reescribimos de cero. Que diantre, ¡cambiamos el concepto de cadena de texto enterito! ¿No nos gusta la sintaxis de algunas operaciones? Pues se cambia a una nueva que nos parezca más moderna, sin problema. También cambiamos el comportamiento de algunas operaciones numéricas que no tenían excesivo sentido ya que estamos. Y añadimos bastante funcionalidad del tirón, que vendrá bien para algunos casos de uso. Tras mucha discusión interna, mucho diseño y mucho desarrollo, ya tenemos Python 3. ¿El único problema? No es compatible con Python 2. ¡Es prácticamente un nuevo lenguaje!

Tener un nuevo intérprete de Python incompatible con todo el código existente (esto son millones y millones de líneas de código de empresas y voluntarios) es un handicap, qué duda cabe. Pero hay un plan. Se plantea una transición larga, de 5 años, y se crean herramientas para ayudar en el proceso. A medida que las grandes librerías migren de Python 2 a Python 3, los usuarios irán siguiendo y llegará un momento en que todo el mundo esté usando Python 3. Para empujar en esa dirección, se decide que Python 2 va a ser abandonado y dejará de recibir nuevas versiones, y el 100% del esfuerzo de desarrollo irá a Python 3. Ya no hay vuelta atrás, el futuro mejor y glorioso está aquí. Sólo hay que esperar esos 5 años para dar tiempo a todo el mundo de dar el paso, no hay prisa.

La desconexión

Python 3 se lanzó el 8 de diciembre de 2008. Hace justo 5 años. La prórroga que el core del proyecto se había dado para su adopción por parte de la comunidad ha expirado. Pero la transición no se ha dado. El grueso de los usuarios de Python no se ha movido de Python 2, pocos proyectos todavía hoy se inician en Python 3. Incluso en la comunidad Hacker News, plagada de early adopters, los resultados de las encuestas dejan a Python 3 en mal lugar. En el “mundo real” las cosas pintan todavía peor. En tan señalada fecha, el debate ha explotado: ¿qué ha pasado con la famosa transición? ¿Qué se ha hecho mal? ¿Por qué no se adopta Python 3?

Los posts al respecto han surgido como setas en las últimas semanas. Toda figura con cierto peso en la comunidad ha querido decir la suya. Los core developers, claro, defienden que Python 3 es el camino a seguir. Algunos opinan sobre cómo debería haberse planteado la transición. Hay quién detalla por qué no va a abandonar Python 2, y algunos tratan de explicar ese comportamiento generalizado (además de proponer extender la vida de Python 2). Incluso se propone añadir compatibilidad con Python 2 a Python 3. También hay gente simplemente mosqueada porque considera que el cambio es a peor, claro. Y luego están los que tratan de poner solución al asunto creando herramientas que compatibilicen ambos con menos esfuerzo (código políglota lo llaman).

Al final, el resumen es sencillo: Python 3 no ofrece mejoras lo bastante jugosas como para compensar el coste de migración. ¿Es mejor lenguaje? Sí, hay bastante acuerdo al respecto. ¿Es mucho mejor lenguaje? No, son mejoras en muchos casos estéticas. Si Python 3 fuese 3 veces más rápido que Python 2, consumiese la mitad de memoria, o aportase funcionalidades totalmente nuevas y necesarias, seguramente esta situación no se hubiese dado. La realidad es que el core team de Python ha dedicado 5 años a crear un producto que la gente no le compra. De hecho, ha creado un producto que nadie le había pedido: se pedían mejoras en Python, no un nuevo Python. 5 años es mucho tiempo, casi un cuarto de la vida del proyecto, como para caer ahora en la cuenta de que quizás no fuese la dirección adecuada. La situación es incómoda, no está muy claro qué viene ahora. Si Python 3 acabará imponiéndose (¿pero cúando?), si tendrá que retomarse Python 2 y llevar poco a poco todas esas novedades de Python 3 a su precursor, o si (esto es poco probable) surgirá un fork que divida la comunidad, poniendo en riesgo el futuro del proyecto.

En cualquier caso, Python se enfrenta a una fase delicada de su ciclo de vida. Causada por una desconexión entre sus desarrolladores (que creen que Python 3 es mucho mejor producto) y sus usuarios (que no valoran esa mejora como para justificar el coste de migrar).

En fin…

Sirva esto como ejemplo de la importancia de adaptar el desarrollo de producto a las necesidades de sus usuarios. El éxito previo, el haber acertado con las decisiones durante años, no le da a nadie carta blanca para ignorar a su público. Un producto nace para ser usado, no para satisfacer el ego de su creador. Tened eso en cuanto cada vez que os sentéis a diseñar o implementar una funcionalidad de vuestro proyecto. Preguntaos “¿Quién me ha pedido esto? ¿Quién me lo va a comprar?”. La alternativa puede ser tirar vuestro tiempo y dinero…

O siempre puede que seáis el nuevo Steve Jobs, claro ;)

 

Advertisements

6 thoughts on “Mejor sí, pero… ¿para quién?

    1. La pregunta del millón, y ahí va mi respuesta del millón ;)

      Creo que hay 3 preguntas principales que formularse para decidir si usar Python 3.

      1. ¿Es un proyecto nuevo o hablamos de migrar uno existente para que su mantenimiento futuro sea en Python 3? Si el proyecto ya existe, yo no lo migraría a menos que sea muy pequeño. Es mucho curro y el retorno no está claro.
      2. ¿Hay dependencias que te aten a Python 2? No todas las librerías gordas están portadas todavía, y muchas de las pequeñas tampoco. A menos que quieras asumir el trabajo de migrarlas tú mismo, lo suyo es quedarse en Python 2 por el momento (lo llaman la gravedad de Python 2).
      3. ¿El proyecto implica implementar protocolos de red? La nueva separación texto/bytes trae bastante cabreados a los implementadores de protocolos (proyectos como Twisted o Werkzeug) que dicen que es más difícil hacerlo en Python 3. Si vas a escribir ese tipo de software, parece que Python 2 tiene cierta ventaja ahí.

      Como muestra un botón: en Ducksboard acabamos de empezar un proyecto gordillo, y lo hemos hecho en Python 2. Algunas librerías que usamos no están portadas, y nunca sabes si la próxima dependencia que añadas al proyecto lo estará. Falta trabajo para que Python 3 sea una opción segura.

      1. Bueno, en primer lugar, las estadísticas de HN no muestran esa tan polémica situación.

        Por otro lado, si todos nos cruzamos de brazos y seguimos esos 3 pasos que comentas, nunca nada se va a portar a python3. Lo que hay que hacer, en mi opinión, es justo lo contrario. Cuanto mas gente lo use, y se plantee usar y mas presión se de a las bibliotecas que se porten, mas rápido se portaran. Estar esperando no da solución a nada pero eso es justo lo que propones con esos 3 pasos.

        Y al respeto del punto 3, igual es algo mas difícil, pero mucho menos propenso a errores. Eso, como mínimo, debería ser la razón para usar python3. Ser propenso a errores nunca es una ventaja…

        Personalmente lo tengo claro, después de desarrollar un software web medianamente “grande” en python3 (portado de python2), no tengo muchas ganas de volver a python2. Y portarlo ha costado muy poco esfuerzo.

        1. Buenas Andrei.

          La encuesta de HN me parece curiosa porque en un entorno mega-geek de early adopters, y 5 años tras el lanzamiento de Python 3, más del 75% reconocen usar Python 2 principalmente en el día a día. Los números fuera de ese entorno son mucho más duros: en palabras del propio Alex Gaynor, en PyPI la instalación de paquetes para Python 3 anda por debajo del 2% del total.

          Sobre mis consejos a la gente que pregunta si Python 2 o 3, trato de ser realista. Si es un proyecto personal o de aprendizaje, adelante con Python 3, sin duda. Pero si es para un tema profesional, no oso empujar a alguien a optar por Python 3 para que luego descubra que oauth2 o gevent o boto no están soportados, y entonces se encuentre con un señor problema. Creo que la opción conservadora es la correcta en estos casos. Si es para proyectos libres, a día de hoy la única opción sensata imho es ir a por políglota (es que lo hacemos nosotros con libsaas).

          Del punto 3 hablo en base a lo que Armin Ronacher o Glyph Lefkowitz llevan años pidiendo (http://bugs.python.org/issue3982). Ellos son los expertos en protocolos, y dicen que la aproximación de Python 3 les limita.

          Estoy contigo en que Python 3 es mejor lenguaje para uso general, desde luego para web sin duda. Me encantaría empezar a usarlo en proyectos de la empresa, pero junto al equipo hemos decidido que es demasiado riesgo debido a las dependencias (tenemos varias que no están migradas, y hacerlo nosotros mismos nos desvía mucho). Quizás en 5 años más :)

          ¡Gracias por comentar!

  1. Pingback: Bocados de Actualidad (182º) | Versvs

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s