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.

Programming on principle

If you only watch a keynote this year, make it this one: Bret Victor – Inventing on Principle.

The serendipity again: I found this video few days after I finished reading Implementation patterns, by Kent Beck. Both two are connected, in the sense that Bret Victor talks about the importance of values and principles in our life and work -with amazing demo examples implementing his particular principle! Beck does the same at the level of programming.

Open Source VS Open Project

«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.