How to measure success in your Inner Source initiative

Nowadays, more and more companies such as PayPal, Bosch or Autodesk are internally implementing inner source programs. Inner source differs from classic open source development process by remaining within the view and control of a single organization and offers many advantages in terms of efficiency and effectiveness.

In previous posts, we talked about Inner source characteristics and advantages such as InnerSourcing: the development model of the future.

Continue reading “How to measure success in your Inner Source initiative”

Dashboard celebrating 25 years of Linux development

To celebrate 25 years of Linux kernel development, we at Bitergia have produced the Linux development history dashboard. This dashboard visualizes the current Linux git repository from two points of view: the history of all commits (changes to the source code) up to now, and the history of all lines in the current version. The dashboard visualizes the main parameters about the development (the who, when and what) are visualized, and allows for drilling down in the data, for example finding the specific commits that lead to a specific part of the code.


Do you want to learn about when the lines in the current kernel were authored? Who has participated in specific areas of the kernel? How many files have remain untouched for more than 10 years? Play with the dashboard and find your own interesting details!

The dashboard was produced using only free, open source software tools (among them, GrimoireLab, our tookit for software development analytics). If you want to learn more details, check the slides I intended to use for my presentation at LinuxCon, which unfortunately I couldn’t attend. Those provide some more insight about how it was produced, some examples about how it can be used, and some curiosities found by exploring it.

Continue reading “Dashboard celebrating 25 years of Linux development”

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”

Blog at

Up ↑