In April, I was promoted to Chair/Tech Lead of Kubernetes SIG-Scheduling. SIG-Scheduling is the team responsible for the development of scheduling-related components in Kubernetes, most notably the Kubernetes Scheduler. I started contributing in 2021, so this is the result of four years of steady effort.
My journey contributing to Kubernetes began in 2021 as a university student, thanks to Google Summer of Code (GSoC). There’s a selection process for GSoC, and I heard that “contributing to the project beforehand can be a good selling point during selection.” So, with slightly ulterior motives, I started contributing to Kubernetes. I’m not sure if that actually had an effect, but I managed to pass the selection and started a project called kube-scheduler-simulator.
Introducing kube-scheduler-simulator By Kensei Nakada (Tetrate) | Kubernetes Blog
When I participated in GSoC, I really couldn’t speak English at all, and I struggled in every 1-on-1 meeting with my mentor. There were a few occasions where I had to speak at SIG-Scheduling community meetings related to my project, but I couldn’t manage any English conversation beyond the parts I had prepared on my cheat sheet… It was quite a disheartening experience. These experiences became a good catalyst for me to start studying English and also marked a major turning point in my career. One of the reasons I chose Mercari for my first job after graduation was the “environment where I could use English,” and now, working for an overseas company, well, life is unpredictable. That said, I still struggle to understand English from people I’m not used to hearing…
I hear that Google Summer of Code is now open to working professionals as well, so if you’re interested, I encourage you to check it out.
After GSoC ended and I started working, I continued to contribute to the main Kubernetes Scheduler codebase as a hobby, little by little. First, on August 23, 2021 (during my GSoC period), I officially became a member of the Kubernetes GitHub Organization. Joining the Kubernetes GitHub Organization isn’t that difficult. If you make a few contributions and ask the reviewers involved at that time, “I’d like to become a GitHub member, would you sponsor me?”, I guess you’ll most likely be accepted.
Then, a year after I started contributing, on May 9, 2022, I joined SIG-Scheduling as a Reviewer. Reviewers are the people who officially handle reviews for the SIG. Specifically, when a pull request is created in an area the SIG is responsible for, review requests will come their way. You also start getting mentioned in various discussions, and it’s around this time you start “feeling like a maintainer.” And on May 30, 2023, I was promoted to Approver for SIG-Scheduling. As the name suggests, Approvers have the powerful authority to give the final approval to pull requests.
There are fairly strict criteria to become a Reviewer or Approver. For example, to become an Approver, you need to have had at least 30 of your pull requests merged. While having strict criteria makes perfect sense, it inevitably leads to a structure where “a small number of Reviewers/Approvers review pull requests from many contributors” across the entire project. Some of you might have experienced submitting a pull request to an open-source project only to have it ignored; this is usually the reason. The number of people with authority is limited, and their time is spent reviewing high-priority pull requests and advancing discussions. Although Kubernetes is a very large and popular open-source project, many SIGs struggle to acquire Reviewer/Approver level contributors because many contributors don’t reach that stage. Conversely, if you have the perseverance to patiently and diligently continue contributing, you’ll likely be able to get promoted smoothly.
After about two more years of working as an Approver, I was nominated and promoted to Tech Lead / Chair. The Tech Lead/Chair is a position that leads the entire SIG, and responsibilities expand significantly, including reviewing KEPs and pull requests, as well as discussing the overall direction of the SIG.
Internally, this discussion had been brought up by the previous leaders about six months prior, and I had been acting as an apprentice during a transition period. SIG-Scheduling already had very few active Reviewers/Approvers, and then all the previous leaders decided to step down simultaneously. Personally, I was thinking, “What are we going to do now…?” but thankfully, Google added a few new full-time contributors, and disaster was averted.
So, although I’ve been an apprentice for six months, I’ve started working in earnest as Tech Lead / Chair from the v1.34 release cycle, collaborating and doing my best with two other new leaders.
I sometimes get asked, “How much do you actually contribute?” I spend about an hour on weekdays, and when I’m free on weekends, I’m basically in front of my computer. If you look at CNCF DevStats, you can see rankings for contribution counts in the Kubernetes repository. I think I’ve been hovering around 5th place for the past few years.
In terms of specific contributions so far, I’ve authored seven Kubernetes Enhancement Proposals (= proposals for major feature changes) to date, and five of them have already been implemented. Among them, the most memorable one is probably QueueingHint. This is an internal feature to better determine when to retry a Pod if its scheduling fails. It’s not a change visible to Kubernetes users, but it required significant changes within the Scheduler, and thus had a large impact on performance, etc. The discussions and implementation were a great learning experience.
Also, along the way, I was fortunate enough to receive Kubernetes Contributor Awards twice (2022: SIG-Scheduling, 2023: SIG-Autoscaling), for which I am very grateful. These awards are announced annually at KubeCon NA. Winning an award gets you a cute plaque like the one below, which makes me quite happy. I especially like the pizza-themed one I got in Chicago.
I think motivation for open source varies greatly from person to person. Some people do it because they have to for work, some to build a track record, some to gain experience, and some simply because they love the technology.
For me, from the beginning until now, it has been purely a hobby. My motivation started simply from thinking, “Isn’t it cool to be a developer for a famous open-source project?” Honestly, at the start, it didn’t have to be Kubernetes at all. I wasn’t even particularly knowledgeable about Kubernetes. It all began when I chose Kubernetes for Google Summer of Code with a vague feeling like, “Kubernetes is a big project, it seems modern, and if I could contribute, that would be awesome, right?” As I mentioned in the previous article, my fundamental trait is being a stimulus junkie. I’m the type who gets excited and more focused when doing something new. A little while ago, I thought this trait was just me being fickle. I didn’t really understand why I, someone who gets bored easily, could continue contributing to Kubernetes. For example, by the time I became a SIG Reviewer or won a Contributor Award, I had more than enough reason to be satisfied with that title and gotten bored.
However, looking back now, I think the reason I didn’t get bored lies precisely in that “stimulus junkie” trait. Kubernetes is a large project, so as you gain more permissions, the scope of what you can do expands. And even now, after more than 10 years, it’s still changing rapidly, with many new features added in every release. Being in the world of Kubernetes has always been stimulating. There was no repetitive work that would make me bored, and discussions about new use cases were always enjoyable. Even now, there are many things I don’t know, and I’m constantly learning. This is probably the sole reason why contributing to Kubernetes continues to be my hobby. Nothing more, nothing less.
However, it’s not like I haven’t gained anything from this activity, even though that’s not my core motivation. This experience clearly worked to my advantage when I was job hunting after graduation, and I’ve changed jobs through connections made in open source. Honestly, without the tangible track record of open-source activities, an insignificant young boy like me wouldn’t get such many opportunities. So, I guess the idea that “open-source contribution leads to career growth” is actually very true.
Furthermore, it goes without saying that I’ve been able to meet many people, both domestically and internationally, through open-source activities. I feel immeasurably fortunate to have formed connections with colleagues across countries and companies whom I would never have interacted with otherwise.
I’m not in a position to say something profound like “Everyone, let’s do open source!” but I want to state here that if you are interested and continue with it, there are significant returns to be had.
Last, but not least… just follow me on GitHub, or buy me a coffee!
