Measuring contributor affiliations is complicated

Illustrated image of an employee ID badge hanging from an orange lanyard

In a comment on the GitHub issue that sparked my post on measuring contributions outside working hours, Clark Boylan wrote:

I suspect that tracking affiliations is a better measure of who is contributing as part of their employment vs those who might be doing so on a volunteer basis.

Unfortunately, this isn’t as easy as it sounds. Let’s explore the complexity with a concrete example. When I was the Fedora Program Manager, I’d occasionally get asked some variation of “what percentage of Fedora contributors are from Red Hat?” The question usually included an implicit “and by ‘from Red Hat’, I mean ‘are working on Fedora as part of their job at Red Hat.'” I never gave a direct answer because I didn’t have one to give. Why not?

What would you say you do here?

The first complication is that there aren’t two classifications of contributor: inside Red Hat and outside Red Hat. There are actually three classifications of contributor:

  1. Red Hat employee working on Fedora as part of their job responsibilities
  2. Person who happens to be a Red Hat employee but not working on Fedora as part of their job responsibilities
  3. Person not working at Red Hat

Because Fedora is a large project with many different work streams, the first two classifications of contributor have a fuzzy boundary. The same person may fit into the first or second category, depending on what they’re doing at the moment. When I was updating the release schedule, I was clearly in the first category. When I was updating the wordgrinder package, I was probably in the second category. Even the general work wasn’t clearly delineated. When I was editing and publishing elections interviews, that was a first category activity. But editing and publishing other Community Blog posts is more akin to a second category activity.

My job responsibilities were somewhat elastic, and my manager encouraged me to jump in where I could reasonably help. This meant I was doing category-two-like activities while “on the clock”. Depending on the context and intent behind the question, the answer to “is this a Red Hat contribution?” could be different for the same work.

Identities are blurry

It’s tempting to say “differentiate activities based on account.” People will use their work account for work things and their personal account for personal things, right? That’s not my experience. By and large, people don’t want to have to switch accounts in the issue tracker, etc., so they don’t unless they have to. A lot of people used their Red Hat email address for Bugzilla, commit messages, etc, regardless of whether the work was directly in scope for their job or not. By the same token, I knew at least one person who used a personal address, even though they were primarily working on stuff Red Hat wanted them to.

In other roles, I’ve seen people use the same GitHub account for work, foundation-led and other third-party open source projects, plus their personal projects. GitHub’s mail rules make that (somewhat) workable. Of course, people can use different emails for their commits based on if they’re contributing for vocation or for avocation. They don’t always.

A final factor

To make it even more complicated, someone might not even have a clear conception of whether or not they were contributing as part of their job or not. And their boss might have a different view. There are some projects that I only participated in because it was part of my job. When I no longer had that job, I stopped participating in the project. Other projects I started participating in on behalf of my employer, but kept participating after I had a new role.

Is a project tangential to my employer’s interests that I’d keep participating in even after I left a work contribution or a non-work contribution? Does it switch from being one to the other? As you can see, what seems simple gets complicated very quickly.

This post’s featured image by Mohamed Hassan from Pixabay.

Ben is the Open Source Community Lead at Kusari. He formerly led open source messaging at Docker and was the Fedora Program Manager for five years. Ben is the author of Program Management for Open Source Projects. Ben is an Open Organization Ambassador and frequent conference speaker. His personal website is Funnel Fiasco.

Share

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.