Areas of Analysis

When analyzing software development projects, there are several areas that can be analyzed. Traditional analysis are focused on code metrics, while the activity, community and process are key components to take into account. This handbook brings into context those areas not that well studied, but key for InnerSource: community and process.

InnerSource is basically all about direct interactions between developers, removing all of the hierarchical aspects remaining in the middle. It is all about creating communities and building social networks that allow the knowledge to fly around. InnerSource is about leaving developers to work with other developers (D2D) jumping over the traditional hierarchies. This helps to increase the development activity, break silos of information and allow innovation within the organization.

• Activity: this component focuses on the basics. Any developer when interacting with the infrastructure of the organization leaves traces of activity. From commits to emails, from tickets activity to code review actions. Any of these traces is potentially measurable and many of these traces from a lot of developers display an organization chart with trends information. Measuring activity means quantifying the basic traces left by the developers. And when this information is aggregated and calculated over time, it is possible to obtain trends about this type of information. Usual activity measurements can be the number of commits up to some date, but also the increase or decrease of such number of commits when comparing to time frames. This can be extended to any potential event that may take place in a community of developers: emails, reviews, opening a ticket, closing a ticket, commenting on a code review or sending an email, but there are others more elaborated such as actions as mentor, newcomers activity, cross-referenced information like tickets referencing pull requests and those referencing commits, etc.

• Community: people are key when talking about InnerSource. If one of the goals consists of flattering the hierarchical structure of an organization, we need to measure how people interact with other developers. Although this is again measured through the traces left by the developers, the analysis proposed are pretty focused on the people and how they build their own social networks. As each developer has her own interests, it is necessary to understand how developers are attracted and retained in a project. What policies are more successful than others when attracting those and who are leaders in the software development process. Usual measurements in this case are related to the analysis of the contributors funnel coming to an internal project, effectiveness of specific policies to attract developers (e.g., hackathons) and others more specialized such as territoriality (how territorial a developer is) or betweenness if we play with some indicators when building networks.

• Process: thus we have a community of developers working together and leaving traces of their activity. But InnerSource is something more than spreading the knowledge across the organization. It is also a matter of reducing the time to market, increasing the velocity of development and building better products. That is the reason why process is also a needed area of analysis. Process can be defined as the bureaucracy followed by the developers to write a piece of code. In a more hierarchical structure, there might be some daily meetings where some decisions are taken and requirements implemented. That is process and if we want to improve that, we need to measure in first place key parameters of such process. In Inner- Source communities, process is quite similar to open source communities where code style, documentation, code review process, continuous integration, design meetings are part of this process. The main difference here is how developers directly interact with other developers, even being from different business units, even been far away geographically. That interaction is the one we need to polish and improve if we want to increase the quality and velocity of the development process. Indeed the ideal goal when improving process is that the total process takes exactly 0 seconds. Once a piece of code comes out of the developers minds, this works, and can be automatically deployed. How can we reach that situation? I do not know, but hey!, at least we can measure that and check how far we are from heaven.

• Code: this aspect of the analysis is probably a well known one. There are usual metrics that determine the complexity of the code, modularity, test coverage, documentation coverage, and others. What we have when measuring this type of metrics is that we can control where our InnerSource method is leading those metrics. Increases in the code complexity or less test coverage may indicate unexpected behaviors that should be fixed and controlled.