2 of 13

Helping track the health of projects...

How can we know if �this open source project is likely to be around in 10 years if we base a product on it?

Is there a diverse community of active contributors engaged in the project?

How can we know if �this open source project is ready to be used by another project?

What is the health of the other projects that this project depends on?

Are there licensing risks in using this open source project?

3 of 13

Mission

Produce integrated, open source software for analyzing software development in terms of these metrics.

Establish implementation-agnostic metrics for measuring community activity, contributions, and health.

4 of 13

Why?

No single health determination can be made across all open source projects, however:

We can start to understand what composite metrics signal and how they can be related to actions

We aim to provide insight as local interpretations are done on the metrics

Provide guideposts for what others have done in similar contexts and how peer communities compare

Develop an understanding of development processes based on facts

5 of 13

Working in an Open Community...

6 of 13

Structure: Focus Around Interests

Metrics

Software

Implementation

agnostic community development metrics

Integrated FOSS tools for software development analytics

7 of 13

Structure: Working Groups for Metrics

Diversity and Inclusion are known to challenge unchecked assumptions and lead to more open and fair collaboration practices.

An OSS community goes through stages of Evolution. The state that a community is in may prove important when evaluating both across and within community concerns.

The Risk metric informs how much risk an OSS community might carry or pose. The evaluation of risk depends on situation and purpose.

Developers and organizations capture Value from engaging in OSS communities. This set of metrics can inform what this value is.

8 of 13

CHAOSS Software

Implement Reference in Open Source

Develop a FLOSS reference implementation of defined metrics.

9 of 13

Retrieval from +30 data sources
Storage of all metadata
Computing of WG metrics
Visualization
Reports

github.com/chaoss/grimoirelab

10 of 13

Prototyping Metrics
Enabling Comparisons
Making Trends Central to the Use Experience

https://github.com/augur

People compare themselves with others. We build on this truth to help people make sense of the metrics we prototype. The aim of the ghData project is threefold:

Fast prototyping of metrics
Be human centered …. Build prototypes that make it possible for people to see a visualization and make sense of it before they become overwhelmed by the information and drown in a sea of data.
Represent trends over time. Its all time these days.

In this slide there are 4 items with specific characteristics in this spirit that we would like you to note.

Comparisons by either Z-Score or relative data. In the case of two projects of comparable size, scope and scale, percentage comparisons can be useful. In many cases, comparing z-scores of project trends yields a visualization with a more valuable view of how the project’s evolved relative to each other over time.
Comparison of the project with itself. How are we doing over time?
Make the project’s ecosystem visible. What are the trends in downloads? What projects are dependent on this one? Upon which projects does this project depend?
Comparisons across projects.

11 of 13

Git-blame tracks changed lines, not tokens

Last person who modified part of a line, becomes “contributor” of the entire line
Cregit is capable of tracking the contributor of each token in a line

In Linux Kernel (cregit.linuxsources.org):

blame per line is accurate in 75%
blame per token (using cregit) is accurate 95%
Results based on statistical sampling and manual analysis, with 95% reliability with +/-5% of error

github.com/cregit

12 of 13

How to Participate

Discussion: Mailing Lists, Meetings, Hangouts, IRC Channels

Code: GitHub

chao ss.communi ty

13 of 13

License & Credits