Brian Proffitt: Open Sourcing for a Living: Determining Organizational Affiliations

gistfile1.txt

"I often ask people at Red Hat is the piece of data you are most interested in?
90% of the time, the answer is, who is working for who, and where people are coming from.  This is the #1 thing people want to know.

We have a problem with organisational diversity at Red Hat. We have found historically, this is not a good thing. 1) no one will want to come in and be part of our organisation.  Perception is that people not part of Red Hat are not welcome (which is not true)
2)The second is the most successful projects are those who had a lot of diversity.  For example when we were part of the larger openstack community, and we are just one part of that.    We were also part of Kubernetes community, and we see huge innovation there.

To give you an example of what we do right - everything is upstream.  I.e. Fedora, because of the way we work, that is one of our most important upstream projects.

What most people don’t realise, only 22% of active contributors in Fedora, are working for Red Hat.  We loved when we heard that, in this community we are doing it right.

Takes of Red Hat - Hat -> Puts on CHAOSS Hat

CHAOSS New release
I was part of organisational metrics.
Why organisations as a rule, that measuring the footprint of an organisation is important because we want to know about contributor diversity.   What is the ration of a single company.


Metric: ‘How dominant are individual organisations in a project?


If we have more than 50% coming from a single company it becomes the elephant in the room.  Now we have become the elephant in the room.  The only way to fix it is to bring people in, but they won’t come in if they think we will not be good players in the ecosystem.


You have influence as an organisation whether you realise it or not.

Other influence - where does it come from, we know that Kubernetes came from Google, we tended to make a bigger deal of that. We don’t know where Google fits in Kubernetes contribution, but suspect they are #1. People will still given social difference because they started it.  We can say that - someone else is #1,  but we can’t ignore the social implications of 

What are we seeking?

We are thinking about these metrics as lego.  And you as  project owners should be able to decide which make sense, and you can put them together. You should be able to decide which questions are being answered.  

(These are all the lego blocks).AKA  ‘Atomic Metrics’

**Metric:** How do organisational partnerships/ collaborations impact the project? 
**Metric**: What are the impact of job changes (organisational affiliation changes) on a project.
**Magnet** or anti-magnet (why are people leaving or coming to your company.
**Metric**:  What is the impact of organisations joining or leaving the project?
**Metric**:  What is organisational affiliation vrs. Non-Organisational affiliation.  (This helps us figure out their needs)
**Metric**: What is the organisational diversity of contributions?  
**Metric**: Who are the drive-by organisational contributors? (We can figure out how to bring them back)
**Metric**: How are leadership positions distributed across organisations. (Meaning who is not Red-hat)
**Metric**: How do financial considerations impact the projects?
**Metric**:   How is code ownership distributed across organisational and non-organisational contributors? (Sometimes this is about people, sometimes about trademarks)


When we put these all together, we can ask bigger questions, what are the roles that people and organizations have, who is leading - do they come in on a governing board, but never show up for meetings.