Key aspects when inner-sourcing your infrastructure

Not everything in inner source is about community building [but a big portion!] and the infrastructure is basic to foster collaboration, transparency and community building.

This post is about aspects to have in mind when deploying the tooling needed to provide support to developers within the organization and across business units.

There is a more extended version of this infrastructure topic in the work-in-progress book about inner source: Managing Inner Source Projects that we, in Bitergia, are writing. Specifically in the infrastructure chapter. This is available under a CC-BY-SA 4.0 license and anyone is more than welcome to propose new sections, improve the current ones and collaborate in any way. Please feel free to redistribute!

Continue reading

Lessons learned when tracking OSS projects (and what Inner Source projects can learn)

[Extra material available at the Open Source Leadership Summit talk and its slides in the Bitergia’s Speakerdeck account]

We are all used to open source projects. Concepts such as community, code review process, continuous integration, geographically distributed contributions, community managers, and a whole myriad of terms and collaborative way of working are usual for all of us. And enterprises are learning from this open process. Those are changing the direction of their development models to a more open one within the organization. Initiatives such as the Inner Source Commons where companies such as PayPal or Bloomberg are publicly exposing their case, help others to deal with the usual problems they face.

Continue reading

Inner Sourcing vs commoditification of software

“The idea is beginning to take root in even the most secretive corporate cultures… Its power lies in the inherent social nature of the creative process. When developers are able to access, use and build upon what their colleagues are creating, innovation can really take hold.”

Phil Granof in Wired

As we detailed in the previous post, adopting Inner Source practices creates great benefits for  companies such as saving cost, faster time to market and enabling innovation.
Commodification of Software
There’s no doubt that Inner source needs a different approach  to project management  but “hands on!” What’s the best project to start Inner Sourcing?

Software is becoming the core of most business, even the traditional ones. However it doesn’t mean that companies should build all the software they need, most of it can be easily bought or outsourced with low cost, in order to focus their efforts on their core business. Thus, Inner Source should help to add value to organizations running away from commodity.

This was the case for Philips Healthcare. Klaas-Jan Stol and Brian Fitzgerald in their article Inner Source—Adopting Open Source Development Practices in Organizations recommended to start with a seed project. That means, not starting from scratch but choosing an existing initial implementation of a software product or component.
Frank Van Der Linden, CTO at Phillips was responsible for and pioneered the setting up Inner Source within the company. He decided to start with a component suite of DICOM (Digital Imaging and Communication in Medicine) standard, used in many medical imaging tools such as x-ray and MRI (Magnetic Resonance Imaging) scanners. Philips Healthcare has a product line for diagnostic techniques in Hospitals, so they chose a core business software product for Inner Sourcing.

Van Der Linden reports enormous business benefits using Inner Sourcing as a process for developing:

  • Three times more product groups served.
  • Substantially improved product quality (Improved feedback from product groups)
  • Product groups find defects earlier.
  • Significant time to market gains.
  • Growing an active Inner Source community – Over 60% of the PH software community involved.

Philips and other companies running Inner Sourcing learned from Open Source projects, they understood how to align and coordinate efforts. In the next post, we will talk about essential tools to enable Inner Sourcing.

Getting your project backlog with GrimoireLab. CoreOS use case

One of the first tasks done by a developer during the day is to choose where to go and what to fix. Backlogs are quite useful for this purpose, either using Kanban and directly having a look at the open issues waiting lists project by project as in the case of GitHub, or using any other manual or automated method.

For this engineering focus we have started to produce some panels whose main purpose is to help developers to make decisions. As this is still in its first stages there is room for improvement, but this hopefully shows how powerful this could be. The displayed panel is part of the open analytics panel produced for the CoreOS community.

backlog_panel_coreos

CoreOS Pull Requests / Issues Backlog panel

This panel aims at providing information at three main levels:

Continue reading

The Mitaka OpenStack mid-cycle quarterly report

[This post is based on the executive summary of the 2015-Q5 OpenStack Community Activity Report, sponsored by the OpenStack Foundation]

The October-Devember 2015 penStack Community Activity Report shows a stable growth of the OpenStack Community. As new repositories and teams keep being added, the number of projects keeps growing. On the other hand it is worth mentioning the decrease in activity during the latest quarters in project teams such as Nova, or stabilization of some others, such as Horizon or Cinder. This is a clear signal of the maturity reached by the some of the project teams in the OpenStack Foundation.

Active Core Reviewers reach a new peak

Although Git activity (changesets merged in the code base) does not show a large increase of activity, if compared to Gerrit, the development effort in the project keeps increasing. This last quarter of 2015 the number of Active Core Reviewers reached a new record of 449 different developers.

Time to merge keeps decreasing

During the third quarter of 2015, a small increase in time to merge seemed to signal a change in trend. However, this last quarter of 2015 keeps the previous decreasing trend. During this period the median time to merge a changeset into master decreased from 2.91 days down to 2.38 days.

Efficiency closing tickets decreases

It is noticeable the decrease of the relative number of tickets closed in OpenStack projects (also known as the efficiency of the ticket closing process). Previous quarters topped at about 60% of closed tickets (with respect to tickets opened during the same period), while this quarter shows a much lower 44%. This could be seen as a poor performance indicator of the project teams.

However, the efficiency closing changesets in the review system (number of changesets merged or abandoned with respect to number of new changesets being proposed for review) remains stable at around 80%.

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

The OpenStack Icehouse release: activity and organizations

[This post is based on the Executive Summary and other sections of the full report about OpenStack and the Icehouse release (part of OpenStack reports) and data retrieved from the OpenStack Activity Board, both developed by Bitergia]

At the moment of this analysis OpenStack projects are close to reach the 74,000 commits since their start as observed in the Activity Board. That activity was developed by more than 2,000 different contributors that at some point started 68,000 code reviews processes and sent and reviewed close to 270,000 different patches. There are more than 33,600 reports in the ticketing system, that were opened by 3,303 different participants. And high activity is also registered in the discussions forums, with close to 52,000 emails messages posted by 2,800 participants and more than 6,200 questions in the OpenStack question and answer tool.

Focus on the development activity, developers can be divided into 246 core developers, 461  with regular activity and 1,214 occasional ones that at some point submitted some patches and contributed to the code.

Structure of the OpenStack community of developers

Structure of the OpenStack community of developers

Continue reading