Today it is the day when Folsom, the new release of OpenStack, is publicly announced. We at Bitergia have been studying it for a while, and today we’re publishing our results as well. So, welcome to the report presenting the charts and numbers showing how OpenStack Folsom was built. For comparison, we’re also presenting a similar report on the previous major release of OpenStack, Essex, released on April, and with a similar release cycle of about six months. Both reports rely on data obtained from the source code management (git) and issue tracking (Launchpad) systems.
[Update, Oct 2 2012, 12:15 GMT. We’ve published some details on the methodology used to produce these reports]
[Update, Sep 28 2012, 16:00 GMT. We have included a new box in the main (summary) page of the study, showing the participation by companies in the 7 projects that OpenStack developers usually considers as “core OpenStack”, and which are those actually subject to the Folsom release cycle.]
The number of commits (changes to source code) is similar in both cases (and more when commits by bots is excluded), which tells about similar coding activity. The number of unique files touched is higher in the case of Essex which suggests that the work is getting more concentrated in certain parts of OpenStack. And the number of companies identified as contributors is quite similar.
However, when we come to a basic analysis of the community of developers (committers), it is easy to appreciate how it is growing, from 47 core developers in Essex to 71 in Folsom, and a similar increment for the whole population. The numbers of the issue tracking system show a similar story.
The list of companies contributing to OpenStack (measured by number of changes to the source code and by number of developers perming those changes) may be also of interest. Rackspace is the first contributor, with about a quarter of all commits, followed closely by RedHat, and at a certain distance by Nebula. Then, with comparable number of commits (but a very diverse number of developers involved) come HP, Isi, Cloudscaling, IBM, Sina, Canonical, Inktank and others.
The situation was more concentrated six months ago. For Essex, Rackspace amounted for most than half the commits. Redhat, Nebula and HP followed at a certain distance, and later came Canonical, Nicira, Citrix, Enovance, Cloudscaling, Isis and others. Looking at these numbers, it is clear that the OpenStack ecosystem of companies is now more leveled, with less dominance by Rackspace, and the clear emergence of other companies which seem to be betting hard to improve the code base.
The rest of this post deals with some methodological details about the report. You can have a look at them, and / or go straight to the full Folsom report, and its sections on general issues (analysis of commits and tickets), analysis per company, and analysis per project. Or you can compare them with those in the Essex report. You can also browse our previous posts, How companies are contributing to OpenStack, and Preview of the analysis of the upcoming OpenStack release which showed some preliminary results, and explained a bit the methodology for the companies analysis (but beware, both were done with only a fraction of the projects in OpenStack, so the data in the final report is much more complete).
The work in OpenStack is organized in several projects, which have a very different size and level of activity. As the chart shows, Nova is clearly the one deserving more attention, with more than 1,500 changes during the preparation of the release. But it is also interesting to notice how the second on is in fact related to documentation, not code (OpenStack Manuals). Libraries supporting the rest of the projects, when taken together, are also experimenting a lot commits. When comparing to Essex, Nova was also very active, but the second one the, Keystone, is now in a modest sixth place. Manuals was much lower than it is now. These shifts in the order by number of commits reflect the changing priorities and needs of OpenStack, which have evolved during the last year.
With respect to the overall size and performance of the whole OpenStack development community, all metrics tell a story of growth over the Folsom release cycle. For tickets, for example, open tickets and ticket openers (usually related to people testing or using the platform, but also to developers who use the ticketing system to schedule activities) grow slightly over the period (see chart on the left). But both closed tickets and developers closing tickets per week show a more clear trend of growth.
The closed tickets chart show the usual peaks (related to more intense periods of bug squashing or ticket cleaning) becoming larger as time passes. The team working to close tickets (ticket closers per week) also grow, with peaks of about 70 developers some weeks.
Graphs for commits (changes to code) and committers (developers performing those changes) also show a growth pattern (see chart below). At the end of the release cycle we’re seeing around 400 commits per week, with more than 70 developers involved every week.
[Note: first and last weeks in the charts usually are low in any parameter, because they are “broken” weeks, with less than 7 days]
With respect to the preview we published some days ago, this report is more comprehensive: it includes most of what OpenStack considers as its projects, including all the core and libraries projects (libraries were excluded in the preview). This has the effect of shaking a bit the list of contributions by company, and some of the aggregated charts. So, even if you had a look at the preview, please go through the final report, it is more complete in the sense of covering a larger part of OpenStack.
[Final note: All the numbers included in this study could still have some errors, but they have already gone through a number of validations, and are correct to our best knowledge. This said, remember you can always download the datasets and do a parallel analysis, if you’re interested.]
