Basic analysis of Zentyal

Zentyal is a free / open source system to manage IT infrastructure, from Internet access to email and network security from a single interface. We at Bitergia have used it as a case example, showing a basic analysis of its source code management repository (git) and its most important mailing lists (managed with mailman). For git, we had a backlog of over 7 years of data, while for mailing lists we had about 2 years. With this information we have produced some basic interactive charts (similar those that were presented in a previous post). [See complete analysis]

[Update, 2012-10-04 11:45: You can also have a look at the slides I used for the talk at the Zentyal Summit where we presented this, in the wider context of how can development metrics help to take decisions about free software]

Zentyal analysis

Screenshot of the Zentyal analysis

The rest of this post discusses some details of the charts, and how they can be used to better understand the history of the project.

Git repository

Charts for the git repository

The analysis of the git repository is presented with the usual charts showing activity per month: commits (changesets), committers (developers actually introducing the changesets in the repository), authors (developers authoring the changesets), branches (parallel lines of development) touched and files touched, with the date period selector at the bottom.

Committers and authors charts clearly show two periods: before and after July 2008. Speaking to experts on Zentyal, we have learned that the source code management repository was migrated during that month, with some loss of history. In particular, we can observe how during the first period, there is only one committer per month, which seems to be due to all commits being attributed to a single actor after the migration. Fortunately, the rest of the history has been preserved, and therefore the different periods of activity and inactivity are observable.

The branches chart shows another transition in source code management system. For all the period before October 2011, it was Subversion (in two different repositories, with a migration in 2008, as was said). After it, git was used. The impact on the branches touched per month is clearly visible. The explanation: git allows for a much more simple and confortable branching/merging, and therefore developers started to use branches more liberally.

As a curiosity, the exceptionally high number of files touched per month in January 2011 means that really a lot of files were changed during that month. Without more information, it is likely that some special activity, such a change in license or in comment headers, or maybe a large rearchitechting of the system took place.

Analysis of mailing lists

Analysis of main Zentyal mailing lists

The charts showing the activity in mailing lists tell about the interactions between persons involved in the project. Starting from the end, the Announce mailing list is probably the least interesting, since it is a broadcast list with no real interaction. But even so, it tells the efforts by the project to communicate about its progresses and any other stuff considered relevant. From some point of view, it is the public communication activity of the project.

Most interesting are Users and Developers mailing lists. Starting with the former, it shows a part of the interaction of the project with its users, and of the users with themselves. With a traffic well below 20 messages per month, it seems quite manageable, while at the same time allows for some feedback and discussions.

The Developers mailing list has a similar traffice, but a very different pattern, with more and more acute peaks. This being a list for developers, peaks usually correspond to hot discussions, where more people tend to participate (this can be shown in the Senders chart as well). There are months when nothing controversial seems to happen, with traffic close to zero messages. Maybe the most important issue that the chart for Developers list is showing is how since April 2012 the traffic is much lower than before. This could mean that discussions and decision taking are happening in some other place, or that the project is not needing these activities. But the latter is strange, since the commit charts show a lot of activity (in fact, much more than in other periods). The introduction of practices related to the use of the ticketing system for discussions could explain this situation (discussions moved to that ticketing system).

In summary, these basic charts show a part of the inner life of Zentyal. Even the casual browser could extract some knowledge about the history of the project form them. But to obtain really useful lessons, more analysis (which give access to more facets of the project) are needed.

8 thoughts on “Basic analysis of Zentyal

  1. Pingback: How metrics help to take decisions about free software? Find out during Zentyal Summit (1 day to go!) | heidi's blog

  2. Pingback: Tomorrow at the LSWC’12 « Bitergia's blog

  3. Pingback: Preview of the analysis of Liferay « Bitergia's blog

  4. J.A. Calvo, it seems that in the previous report we have also all the history. I have redone the analysis and the time window in github is also from 2005-06-27, so in this report we have the full story. In any case, I have updated the report and after some checking we will upload the updated version!

    Do you plan to migrate from Track tickets also to Github issues?

    Keep up this cool project!!!

  5. Yes, the history (the commits) was ok, but not the authors, all the different authors of the first years were credited as a single author called “unknown”, now we have recovered the proper names🙂

    And yes, we have already thought about dropping trac in favour of the github issues, but as it will also require to move all the information on the trac wiki, that takes some time, and we can’t do it right now.

  6. Yes jcalvofer you are right, the authors are now completed with the new data. We will upload the new report with this authors info!

    About migrating all to Github, I am not sure about how difficult is to migrate issues from Trac to Github. I suppose you could use some APIs to export and import the data and then, fix specific issues. And about the Wiki, more or less the same. I am really interesting in this migration if you finally do it.

    We have support for github issues so if you migrate to issues we will update the report with this new info. Wiki metrics support is in our ROADMAP but we have to develop a new tool from zero.

    Thank you very much!!!

Leave a Reply

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

You are commenting using your 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