Identity matters in open source, but not how you might think. For example, Lili Cosic works for Red Hat, and she’s also a maintainer within the Kubernetes community, responsible for kube-state-metrics. While Red Hat encourages Cosic in her Kubernetes work, they don’t control her involvement. Open source is a separate, personal thing. Or, as Cosic described it in an interview, in open source “You always wear the corporate hat, but you wear a maintainer hat and you always want to make sure you separate that.”
But getting to wear that open source hat at all? That started long before when she was 13 and her mother bought her a computer, leading to development of “small things like scripts or web pages or things like that.” Her coding didn’t stop there, however, and it’s worth understanding the process by which she became a Kubernetes maintainer, and how her employment with Red Hat relates to it.
[ Also on InfoWorld: What does an open source maintainer do after burnout? ]
Consistency is the key in open source contributions
Cosic’s first open source contribution wasn’t particularly auspicious. According to Cosic, her open source evolution began with a typo: “I opened a pull request to fix something in the Docker ReadMe doc. I think that’s the majority of the people’s experience. I think everyone has that one typo they see somewhere and I think that’s the first experience a lot of people have.” Encouraged by the ability to participate and make a project better, Cosic pushed her involvement up a notch. Or several.
Cosic’s contributions weren’t the major features for Kubernetes or other projects. Indeed, she said this isn’t the ideal way to contribute. In Cosic’s words:
Consistency is the key. Regardless if you contribute large pieces of code or small, it’s more about consistently contributing over a period of time. Usually you need to contribute at least for a few months consistently, which includes reviewing pull requests and answering issues on GitHub Issues or on mailing lists or Slack or something like that. [In fact] it’s better to contribute smaller pieces so you get to know the entire code base basically. If you only contribute one huge feature you will never know the entire code base. Yes, you might become the maintainer of that one feature, but not of the entire project.
Her interest in contributing has been helped by the Kubernetes approach to community.
What the Kubernetes community gets right
By many accounts, Kubernetes is different. While Linux has a reputation for being an occasionally caustic community, Kubernetes is welcoming, according to Cosic: “It’s not perfect, but the Kubernetes community is one of the more welcoming [open source communities].”
When asked to identify why this might be, she pointed to Google: “I think it has a lot to do with the fact that a lot of the Google Summer of Code (GSoC) mentees were women. For example, you have Nikhita [Raghunath] who now is part of the Kubernetes Steering Committee, was part of GSoC in 2017. Of course, we’re not there percentage-wise, but it is more encouraging.”
One benefit of Kubernetes, she continued, is that it’s a community that could start with a clean slate, rather than a well-established project with a history to uphold (or overcome). The Kubernetes community, for its part, is intentionally inclusive, she said: “CNCF has an entire team meant just for improving the contribution experience, which helps a lot. They put a lot of effort into being welcoming to new people.”
It seems an emotionally healthy thing to feel a certain degree of “imposter syndrome,” but for underrepresented groups in tech, this can be harder to overcome. By creating a “welcoming atmosphere,” Cosic suggested, “In the long run it will create more diversity in the kinds of contributors you can have.” This, in turn, leads to better software.
The war of the two hats
Such diversity, however, doesn’t really have anything to do with the companies paying the developers’ salaries. It’s the developers themselves who are recognized within a project. It’s convenient to assume an engineer who works for, say, IBM contributes code to this or that project for IBM. While this may be true for projects in which IBM is the dominant (or sole) contributor, it’s not true of open source, generally. The Apache Software Foundation, for example, is very explicit on this point: “We firmly believe in hats. Your role at the ASF is one assigned to you personally, and is bestowed on you by your peers. It is not tied to your job or current employer or company.”
Cosic was equally plainspoken when I asked her how her work on Red Hat OpenShift impacts her work on Kubernetes: “You always wear two hats. You always wear the corporate hat, but you wear a maintainer hat and you always want to make sure you separate that. You always want to make sure you do it for the good of the project.”
But surely her work with kube-state-metrics puts her in a position to change the project to benefit Red Hat?
Maintainers are not necessarily people who do feature work. They’re there to make sure the project is healthy…. [A]nytime I make a decision in terms of features, I never think of it from a Red Hat point of view. I think, “Is this something that the project is meant for?” Recently there was one person within Red Hat who opened a feature, and it’s not something kube-state-metrics is meant to do, so we rejected it. We have to live by those standards. It’s not a Red Hat project. It’s a project for the community. My Red Hat job doesn’t necessarily define the projects I maintain. They only define my work time. Whenever someone from Red Hat says, “I want this feature in kube-state-metrics,” I will always wear my maintainer hat versus my Red Hat hat.
So when Cosic meets (virtually now that we live in COVID land) with the two other maintainers for kube-state-metrics, they don’t talk about what this or that vendor wants in their upcoming 2.0 release. They simply discuss what is needed to advance the project from a maintainability perspective, including removing technical debt and figuring out which kinds of data to collect.
It’s how open source is meant to work: individuals, as individuals, working together as communities to make great software. For Cosic and the Kubernetes community, it appears that open source is working as advertised.