Kilo: the new OpenStack release

[Updated results based on methodological changes]

Kilo, the new OpenStack release, shows a continuous increase of activity if compared to Juno. From Icehouse to Juno, there was an increase of 6.22% in the number of commits and 17,07% in the number of unique authors. From Juno to Kilo, there’s a higher jump in terms of commits (11,23%) and a lower increase in terms of authors (11,16%). However, with this increase, there is a new peak in the number of unique authors contributing to the OpenStack Foundation projects with close to 1,600 different people participating in its development.

Continue reading “Kilo: the new OpenStack release”

Behind the big numbers on the Wikimedia code review process

Having a dashboard usually opens new paths to understand software development communities. This may be seen as the entry point that helps to understand the basics of a community. And on top of this, there may appear new questions related to those basics or to more advanced issues. This is the case of the new work we are working on with the Wikimedia community metrics analytics team: Core Reviewer and Participants.

  • Core reviewers are defined as those developers that can exercise a +2/-2 review in Gerrit. In addition to this, it is of interest for the community to remove auto merges. Although this is an undesired behaviour, that takes place, and those should be removed.
  • On the other hand, Participants in Gerrit are defined as any member leaving any type of trace in the system. In this set we can find reviews (-2,-1,+1,+2), uploads, comments and others.

It is interesting to notice that depending on the community, requirements are slightly different. In the case of the OpenStack community, there are extra requirements for the Core Reviewer definition. And this is that reviews should be found in master branch. This specific measure can be found in the OpenStack quarterly reports for each of the projects of the Foundation.

Continue reading “Behind the big numbers on the Wikimedia code review process”

Analyzing Risks associated to FLOSS Communities

Bitergia participated in the last LinuxTag event in Berlin that brought together the industry and FLOSS (Free/Libre/Open Source Software) communities in the same event.

I had the pleasure to present the basics of the analysis of FLOSS communities from a quantitative point of view, specifically focusing on the analysis of companies. Openstack was the project selected as a case study, where volunteers and companies are working together to build an open source software to build public or private clouds.

Among other questions,

  • Main developers
  • Understand who are the main developers: a company could be interested in hiring them or providing some financial support for specific activities.
  • Typical patterns of activity: in order to guess the effort that is being actually developed.
  • Regeneration of developers: turnover is almost impossible to avoid, but some policies could be derived in order to avoid knowledge loss.
  • Study of companies participating: some companies could be interested in better understanding what other companies are doing and the regions of the source code that they are modifying. Or even their importance in terms of number of developers and overall productivity.
  • Responsiveness of the community: when fixing issues in the source code, process is usually undertaken in the issue tracking systems or for instance, support provided in the mailing lists or forums.
  • Evolution of licensing and issues derived from them: this is probably a key difficulty when redistributing source code and integrating third part software
  • Orphaned areas of the source code that might be more prone to be buggy as well as low maintained areas of the source code.

From this perspective, companies, public administrations or other actors in the open source world might be interested:
Continue reading “Analyzing Risks associated to FLOSS Communities”

Powered by WordPress.com.

Up ↑