La liberación de patentes que salvó al coche eléctrico

Siguiendo los pasos de TESLA, hace 1 año, BMW y otros muchos liberaron las patentes relacionadas con baterías eléctricas para coches. El eléctrico era una “revolución” que se hacía esperar y supone todavía un mercado minúsculo con respecto al de combustión. Sin embargo, hace unos meses BMW ha anunciado que en 10 años todos sus modelos serán eléctricos y el resto de fabricantes tienen planes similares.

Por qué TESLA libera sus patentes

Luego de la noticia, lo primero de pensé fue: ¿por qué? ¿qué pretende conseguir? Más allá de que podamos tachar a Musk de visionario o filántropo, ese movimiento no me parecía ajeno a la lógica de las leyes económicas. Muy pronto, en mis círculos, se equiparó el caso a las contribuciones gratuitas que IBM, Fedora, Google y otras compañías hacen al núcleo de Linux, al kernel. Cosas como que IBM contribuía porque la existencia del kernel le permitía reducir los márgenes comerciales en la venta de equipos ya que no tenía que construir por sí mismo un kernel ni pagárselo a terceros. Lo que contribuía era menor que lo que debería invertir para hacer su propio kernel. Yo también creía que esta analogía sin duda era acertada pero dejaba la pregunta principal sin responder: ¿cuáles eran los márgenes que TESLA quería mejorar? ¿y cuál era el kernel de la industria de coches eléctricos?

Durante unas semanas hice seguimiento de la noticia para tratar de entenderlo. La respuesta requería cierto conocimiento del sector del automóvil que no tenía y me costó ver la pintura. De las 250 patentes liberadas, 130 y las más importantes se referían a los sistemas de recarga y las baterías. El propio Musk lo confirma días después a la prensa. Por lo tanto, un titular alternativo para la noticia sería:

Por favor, usen ustedes nuestras baterías

Es decir, el núcleo de la industria del coche eléctrico son las baterías y los sistemas de recarga. Con este movimiento, TESLA estaría buscando que su sistema y modelos de baterías se convirtieran en el estándar.

En busca del estándar perdido

Los meses anteriores a la liberación, TESLA había intentado colaborar con otros fabricantes para que adoptasen su modelo, pero el propio Musk habría dicho que no fueron movimientos fructíferos. Según los expertos del sector, los sistemas de TESLA eran realmente buenos y mejores que los de sus competidores: la red de recarga y el sistema de baterías era mucho más duradero y rápido que las demás. Aún así, algunos fabricantes descartaron su uso, bien para no depender de TESLA bien porque quería explorar otras ideas tecnológicas. Como agravante, el mercado de baterías se estaba moviendo hacia baterías planas, lo que ponía en entredicho la posición de TESLA (que usaba circulares) y sus planes para construir una gigafactoría. El apoyo inicial de empresas como Panasonic para construirla estaba en entredicho y se decía abiertamente que el plan podría ser un suicidio porque TESLA estaría fabricando baterías que el mercado no compraría. Ante estos rumores, en TESLA habrían dicho que ellos no están ligados a un único tipo de baterías y que podrían cambiarlas cuando el mercado de las planas esté maduro.

Seguramente este contexto fue el que movió a Musk a buscar otra vía: si nadie quiere comprar nuestros sistemas, convirtámolos en un estándar.

Los efectos económicos de la apertura

TESLA, sobre todo, tenía un miedo principal: haber llegado al mercado demasiado pronto. No tener músculo económico suficiente para aguantar hasta que el mercado del eléctrico por fin explotase. Con la gran base instalada de coches de combustión y redes de recarga, es imposible que sin el resto de la industria ese cambio se pudiese realizar sin dilapilar más dinero y tiempo del que TESLA disponía. Entonces, ¿cómo la liberación de patentes les ayudaría?

Los efectos económicos de este movimiento eran varios. Por un lado, supondría una aceleración de las economías de escala en la producción de baterías, reduciendo los costes e incertidumbre asociadas a los sistemas TESLA en una especie de profecía autocumplida: si más gente colabora y los usa, sin duda tienen futuro. A su vez, la liberación de recursos económicos que ya no van a la investigación de baterías y sistemas de recarga supondría que la competencia en el sector se desplazaría hacia otros lugares de la cadena de valor, acelerando la adopción del coche eléctrico. Finalmente, la super-red de carga de TESLA tendría grandes opciones de convertirse en el estandar de facto gracias a los efectos red que supone llegar antes que los demás.

El caso de TESLA es sin duda interesantísimo. Lo que me pareció llamativo es lo que supone de afirmación: para acelerar la adopción de un estándar e incrementar la innovación es mejor un sistema abierto y competir sobre un núcleo común. Ésa era la apuesta de TESLA y la que aceptaron el resto de fabricantes. Es una lección que en la industria del software hemos aprendido en los últimos 20 años de manera acelerada gracias al software libre, pero seguramente este caso se vuelva mucho más visible y común en las escuelas de negocio por lo que tiene de mainstream el sector del automóvil. Es una buena noticia para el mundo libre.

Software never lies

«When you run a business, if your software has a bug, your customers don’t care if it is your fault or Linus’ or some random Rails developer’s. They care that your software is bugged. Everyone’s software becomes my software because all of their bugs are my bugs. When something goes wrong, you need to seek out what is broken, and you need to fix it.»

Or why you should read the source if your shop sells custom apps on top of a framework. HN original post. This is a recurrent theme in this blog: The costs of going it aloneWorking with upstream: an interview with Lazslo Peter.

Analysis of free software communities: coda

As you can see in my last posts (I, II, III, IV and V), I finally managed to translate the paper we released last year in V jornadas de SIG Libre (please, beg my english!). It took me a year and my wisdom teeth removed to find the time.

Our intention (Fran and me) when this paper first poped out from our heads was to foster debate on the best practices around a free software project. While at CartoLab, we presented the idea to Alberto; he encouraged us to work on it and gave the time and resources needed; also in the later stages he contributed to polish the trends and conclusions. I’m deeply grateful for all his patience and empathy.

I’m very proud of the work we have done: the first study of this kind in the GIS arena, and somehow a picture of 10 years of FOSS4G software development (for the desktop side). I hope the study is worth the effort and it continues to create debates on how to better work together.

Analysis of free software communities (V): generational analysis

Disclaimer – this post is part of a serie: IIIIIIIV and V (this one).

  • Images: on the left, contributions of top 3 developers along the project history; on the right, evolution of developers participating during 2010.
  • Datatrunk from project repositories during the period 1999-2010.

Is it something we could extrapolate from the data there?

This indicator gives us some sense on how the leadership changed and how the knowledge transfer was done in every project. The paper elaborates a bit more the points of turnover and integration of new blood in the project (highly correlated with this indicator) with statistics of top 10 developers.

All that will give us some insights on every project:

GRASS

  • The charts and data depict how a new generation took over the leadership from 2005 onwards. The process seems to be happened in a very organic way -in the sense that people grew its skills at a steady pace for a long time- and also deep to the roots: from the top10 only 4 out of 10 people continue collaborating with the project.
  • The data also shows how the top3 represent half of the work in the project, which suggest that several developers are highly involved with no one having too much influence (actually, the top contributor during 2010 means 40% of work).

gvSIG

  • The charts and data depict a highly distributed team with a high rate of turnover. Top3 is responsible for less than half of the contributions, being top10 around 60%. The change of leadership happened very quickly around 2007 and only 2 out of 10 contributors from top 10 kept working in 2010.
  • Besides, the top10 shows a homogeneous involvement in terms of number of contributions, which may reflect that all of them had a similar role and impact in the development of gvSIG.

QGIS

  • The charts and data depict a project dependent of its top3 with a contributions-friendly culture. Top3 activity means a hight rate of contributions over total but seems they have integrated well new blood as 9 out of 10 most active developers working in QGIS have started in different years and continue involved.
  • Top10 people have different ratios of involvement, ranging from 6% to 50%, which may reflect the heterogeneity of its core developer base (from volunteers to full-time developers).

Analysis of free software communities (IV): community workhours

Disclaimer – this post is part of a serie: IIIIII, IV (this one) and V.

  • Images: on the left, number of changes to the codebase (commits) agregated by hour of day. On the right, number of commits grouped by day.
  • Datatrunk from project repositories during the period 1999-2010.

Is it something we could extrapolate from the data there?

This indicator is intended to give us some information on the patterns of behavior of contributors. Specifically, we can track how is a typical week for the core developers in every project: the timeline shows when the integration happened, don’t reflect the time in which the work was done; so it’s telling us the history of people with commit permissions, what we know as the leaders.

Let’s try to extract some information from there:

GRASS

  • Internationalization: the hourly chart represents a gauss bell centered on 15h GMT, which in most European countries would be after lunch, being morning in the Americas. That could reflect that both continents represent the vast majority of core commiters. Nevertheless, the work is relatively well distributed along different hourly zones.
  • Volunteers: the daily chart shows a light drop of work during the weekend, likely due to hired developers or people who likely make contributions mostly within their working hours. Nevertheless, there is still a high rate of contributions being integrated during weekend, which may be a sign of a well stablished volunteer base of core-developers.

gvSIG

  • Internationalization: almost all the integration happens in a journey from Monday to Friday, with a hourly range from 09:00 to 20:00 GMT. That is strongly correlated to the hours of opening of a typical shop in Spain and reflects the nature on how the application was built in that period: led by a public body which contracted development to Spanish firms.
  • Volunteers: seems that volunteer work in core was reaching to none, which reflects the original nature of the project in that period.

QGIS

  • Internationalization: the hourly chart is nearly to a plain rate of contributions, which is a strong sign of a highly distributed leadership along the world. It’s even difficult to suggest which zones would be the prominent in terms of developers.
  • Volunteers: the daily chart reflects a steady work along the week, with no signs of falling during the weekend, which may be related to a strong base of volunteers core commiters.

«An open project and its community are the sum of individual people doing what they care about. It’s flat-out wrong to think that any healthy open project is a pool of developers who can be assigned priorities that “make sense” globally. There’s no product manager. The community priorities are simply the union of all community-member priorities.»

— Havoc Pennington, A few thoughts on open projects

A lot of experience condensed in every word.