An interview with Jaice Singer DuMars, Sr. Director of Open Source Software Engineering, VMware.
Jaice discusses Kubernetes — the tech, their career journey and extensive contributions, and the community’s thriving spirit of inclusion that had made them feel at home for the first time.
Hi Jaice, a belated welcome to VMware and thank you for taking the time to speak with me today.
Glad to be here!
In the immortal words of Yogi Berra, “the future ain’t what it used to be.” How are you and your team holding up through these unprecedented times?
I think we are all doing as well as can be expected given the challenging circumstances. For me, the pandemic has underscored the importance of people and relationships in life, and how truly fleeting everything is, and can be. At work, that translates into ensuring my teams have the time and psychological safety to take care of themselves and their families. People are always first. I am really proud of the work that folks are doing, and am always in search of ways to support that.
As someone who’s worked in and around Open Source for their entire career, could you tell us what attracted you to this role at VMware?
Certainly. I saw what VMware is doing and how it’s in this incredible position to solve the hybrid and multi-cloud problem, which is starting to be known as the “supercloud.” Open source software is now a non-negotiable element of this solution space because it acts as a hedge against lock-in, provides much more agency to adopters, and benefits from a globally-diverse set of folks. With the rise in cloud native software, the reliance on healthy, functional, and inclusive communities is inextricable from that model. Kubernetes laid this groundwork, and it has proven to be an enduring differentiator.
Let’s expand on Kubernetes if you don’t mind. Could you tell us how Kubernetes works and the way it provides significant advantages for IT and development efforts?
Kubernetes is an open source system for automating deployment, scaling, and management of containerized applications. It groups containers that make up an application into logical units for easy management and discovery. Kubernetes was an evolution inspired by 15 years of experience running production workloads at Google, combined with best-of-breed ideas and practices from the community. In the multi-cloud paradigm, it provides that magic underlayment that can harness environments anywhere — from data centers to clouds to edge. It’s really the cornerstone of future infrastructure strategy.
What impact has Kubernetes had in the open source community at large?
Kubernetes has transformed the way people think about open source, its purpose, participating in it, and how it gets built and deployed. One of the key differentiators with Kubernetes is how it contributed to the democratization of infrastructure as a service. It required a fairly broad set of contributors to agree on how to do things amid competition from those seeking to make the space serve as a market opportunity for their products.
Open source, in the past, has been a lot about just software and the different models that have been rolled out over the years. The community aspect of Kubernetes, one of the core drivers of its success, created a seat at the table for everyone, including myself. We’ve never seen such a meteoric rise in the open source community, which can be directly attributed to Kubernetes’ vast number of contributors and associated activities. It’s hard to believe so much has changed since June 6th, 2014 when Joe Beda pushed that first Kubernetes commit to GitHub!
How and when did you first learn about Kubernetes? Where did it all begin for you?
I had been working in open source, managing technical operations at Rally Software when it became abundantly clear in the fall of 2014 that we needed a platform to orchestrate our growing containerized infrastructure. There were many options, but none of them fit our needs. A colleague eventually told me about an exciting new project called Kubernetes. We put it through various test scenarios, but it wasn’t mature enough to run our production applications. So, we did what companies did at the time and created our own home-grown solution.
What happened next?
In February 2015, I interviewed for an engineering job at Deis (now Microsoft). I was wrestling with stepping into a higher level executive management position or going back to being an individual contributor with the flexibility of working remotely. I loved my career as an engineering director, but I missed solving problems directly. The Deis team made the decision for me, and I joined them.
I presume you had a supervisor or colleague at Deis who kickstarted your involvement in Kubernetes?
True. I had a colleague at Deis — a DevOps true believer — who had devoted his career to making it easier for companies to implement a completely container-based PaaS. His passion for developer empowerment in cloud native technologies was infectious. When we spoke during our first meeting, he brought up Kubernetes and how it was going to be the foundation for Deis moving forward. And, more than that, he rightfully predicted that Kubernetes would become a cornerstone of cloud native technologies.
Starting the job at Deis was equal parts exhilarating and exhausting; I had to dust off my engineering skills on top of grokking completely new things. A crucial priority was learning Kubernetes, its implementation mechanisms, and failure patterns. I wrote the somewhat infamous etcdeath suite of “failure overlays” so we could analyze what happened in Kubernetes when etcd became unstable or unavailable. I tinkered with early installation tools and discovered that building and upgrading production clusters was not super straightforward. Luckily the project, and especially CoreOS, had outstanding documentation. I also happened to work with an amazing team. I was along for the ride as Helm blossomed into an indispensable part of the Kubernetes ecosystem.
When did joining the Kubernetes community appear on the horizon?
A few months into the job, my technical confidence started to return, and my boss told me we needed to contribute more to the Kubernetes community. I’m one of those people that suffers from “impostor syndrome” where no matter how much you know, you never feel like you know anything at all, especially compared to everyone else — my upbringing had taught me that. So, the thought of getting involved with a community was unnerving. Additionally, I had spent the prior three months sequestered getting my Kubernetes/engineering tech skills sharpened and not paying much attention to the community, or even human beings in general. It was an endless string of 14-18 hour days building/destroying clusters, writing Terraform, testing code, and most of all, learning.
For many people, joining an open source community, like Kubernetes, is unnerving. Could you expand on how you made the leap into working in the K8s community and why it really clicked for you?
Prior to my introduction to the Kubernetes community, I attended my very first Special Interest Group (SIG) meeting, which was SIG Cluster Operations, or SIG-Cluster-Ops, as it was known before it disbanded. The leads were Mike Danese from Google and Rob Hirschfeld from RackN. The group was working on early reference architecture diagrams and providing a place for operators to share experiences from their production implementations. It was amazing. I felt so welcomed, and kindred with everyone there. No one felt shy about asking questions, or admitting their clusters were not perfect. It was my first taste of the Kubernetes spirit that thrives in the community today. It’s also interesting that the SIG didn’t last, because getting solid end-user and customer feedback into the project continues to be a challenge.
The following week, I attended my first Kubernetes community meeting where the worldwide community gathered to see demos, talk about releases, and share events, ideas, and camaraderie. At the time, meetings were almost exclusively organized and facilitated by Google’s Sarah Novotny who was the revolutionary force behind Kubernetes’ community strategy. Again, I felt at home. In that meeting, someone traditionally volunteers to take notes in a Google document. No one had stepped up yet, so I did. It was tough, and a little tricky since I didn’t know anyone’s names or voices yet. It would be the first of my many contributions of note-taking on behalf of the community. I did my best, and that’s all anyone ever expected from me.
Once you embarked on your Kubernetes journey within the Community, where did it take you?
After Kubernetes 1.2 was released, I realized that there were a lot more opportunities to help than just taking notes, if I was brave enough to step forward. All the leadership skills I had honed throughout my engineering leadership career, like managing large, distributed teams, running retrospectives, overseeing Agile release trains, had a home in the community somewhere. I stepped up into SIG leadership and volunteered to run the 1.3 release retrospective. The morning of that meeting I was so nervous it felt like my stomach was a box of ferrets and I had to fend off the little voice inside my head, taunting “you’re an outsider” and “you don’t even write code in the project.” Again, I did my best. And you know what? The retro was a success since many improvements surfaced. People felt it was valuable, and it raised awareness of things we could do better. It went so well, in fact, that we had to schedule an additional hour to the meeting. Because I felt like I was among friends, not just colleagues, the ferrets turned into mice, and I was less nervous the second time.
Since then, I facilitated every release retrospective until handing it off for… 1.10? 1.11?, and it still bears a lot of fruitful opportunities for improvement. In the 1.7 retrospective, my sense of belonging to the community grew even stronger and my concerns and frustrations and not feeling like I had a home evaporated. And that’s how I feel pretty much all the time now which is a really big deal for me. I’m a serious introvert and I have never been good at making friends. I love people and I love servant leadership, but friendship has always been elusive to me.
From that point, I went on to lead two Kubernetes releases (1.8 and 1.10), lead SIG Release, SIG Architecture, SIG Azure, SIG PM, serve 2 years on the code of conduct committee, be a community moderator, Slack admin, election officer, and various other leadership roles. I helped define a lot of what are considered “normal” operations for Kubernetes, and I am really proud to have sponsored many under-represented folks in the project to help them grow into leadership. I’ve been asked to run for the steering committee nearly every time, and I always say no in favor of instilling confidence in someone else who can present a more inclusive experience. I have a pretty good track record in nominating people.
In a very personal article, you wrote about the turmoil of growing up and later finding a home in the Kubernetes community. You stated when it comes to diversity and inclusion, there’s a thin line between thriving and surviving. Could you tell us about that?
As communities, we need to continue along the path of openness, allowing people like me to stop carrying the dead weight around of feeling like an impostor. Being able to show up as you are and be supported is one of the greatest gifts we can give each other. Seek out the greatness in others and help them shine a light on it. When you see someone struggling, give them a hand or kind word. Be kind. Always. That’s how a community thrives, and leads to a natural ecosystem of diversity and inclusion. There is a lot of inertia in most systems that pushes ‘isms’ forward, even when people don’t intend to. You have to learn to see it and counteract it in yourself first, and then help others reach the same conclusions.
What advice would you give to someone who’s still apprehensive about getting their feet wet in Kubernetes or an alternative open source community? Should they follow their curiosity and just jump into joining a community?
Keep in mind that a lot of the folks participating in open source communities aren’t full time software developers. There are other tasks to be done beside the real technical stuff, such as taking notes like I did starting out. Many people are there participating simply to lend support to the community and provide technical camaraderie and collaboration. You don’t have to be anything other than open and inclusive and caring about the community. That’s a great barrier to entry, right? Just that you care.
Secondly, curiosity is the door that everyone can open, but sadly don’t. Open source and curiosity are very linked, and if people aren’t ready to jump into a community, then checking out the Linux Foundation and the Cloud Native Computing Foundation (CNCF) is a good place to start. These organizations foster broad coalitions in several technology areas and provide a place for someone who has general curiosity to enter in their area of interest and get involved.
“Curiosity is the door that everyone can open, but sadly don’t.”
– Jaice Singer DuMars
Are there any last words you’d like to say about Kubernetes and the impact of community as a whole?
There have been articles written about Kubernetes, not only citing that it’s a path to extraordinary software but highlighting the strength of its community as a major differentiator among other open source projects. That is certainly true. But what’s more is Kubernetes is a way to change lives for the better, no matter how hokey that sounds. Yes, there are differences, squabbles, and occasionally strife. But that’s what you see in any group of people trying to get something big done. The difference is how we — me included — support one another to find solutions. Nowadays in a meeting, you can count on someone always taking notes. If someone from a SIG can’t host, someone else will step in and do it. We all care about transparency and authenticity in our actions. We all do our best and show up in whatever capacity we can. And that’s always enough.
“Today, my life is so much better. So much richer. That’s what community at its best does. It gives us a sense of belonging. It laughs with us, not at us. It learns alongside us, not at our expense. It teaches, nurtures, and enables. It builds and does not destroy. It makes us all better.”
– Jaice Singer DuMars
This interview has been edited and condensed for length and clarity.
Stay tuned to the Open Source Blog and follow us on Twitter for more deep dives into the world of open source contributing.
