Yoshiya Eto | 07 June 2024
Note: This article is based on an email interview with Mr. Yoshiya Eto, a Fellow of The Linux Foundation. In the following text, “I” refers to Mr. Eto’s first-person narrative. The story starts with Mr. Eto’s university life.
When I was at university, my research topic was object recognition (i.e., capturing the picture of an object). I believe it is now commonly called artificial intelligence. This research required massive computing power; however, at that time, we just had 16-bit 80286 processors and the MS-DOS operating system. In my graduating year, our lab purchased an MC68020 base 32-bit UNIX machine. At the same time, the university purchased VAX-11/382, which could run BSD4.2. However, as students, we were not allowed to modify the BSD4.2 source code. Therefore, we established a group that met, studied, and read the code. This was my first opportunity to study the BSD4.2 kernel code and my first exposure to BSD license open source software. From that moment on, I was interested in understanding the operating system.
After graduation, I worked for Fujitsu. I was very lucky because I was able to develop a novel operating system, from scratch, for my first job!
I continued developing and supporting this operating system for 15 years. During that time, I also studied several processor architectures and ported NetBSD to SPARC processor-based workstations. Additionally, I sent a small patch to the NetBSD mailing list to enable a specific SPARC processor. This was my first contribution to open source software. And, of course, that patch was quickly included in the mainline NetBSD kernel.
In 2000, Fujitsu chose Linux as its next-generation operating system for mission-critical systems. At the same time, we made our IP public. Then, in 2001, Fujitsu, IBM, Hitachi, and NEC began collaborating to enhance the features of the Linux operating system for use in each enterprise (see this article: https://pr.fujitsu.com/en/news/2001/05/30-1.html).
I ran a team of special development and operating system design engineers, and in 2002, we were heavily involved in this project. Because of my extensive experience developing operating systems, and because of the quality engineers on my team, developing new features was not too tough for us! I thought I could clearly see what features were lacking in the enterprise/mission-critical systems and understand what needed to be developed in the Linux system. However, what I didn’t understand was how collaborative the Linux community was and how new developments were undertaken and dispersed throughout that community. Through this process, we all worked together (from company leaders to our newest employees) and gained a deeper understanding of the Linux Foundation and its community.
Some of the things we accomplished during this time were:
- Forming an OSDL/Linux Foundation to help develop features.
- Hosting an event where key developers in all communities had an opportunity to directly communicate.
- Gaining IBM/Intel support for our upstreaming.
To utilize these opportunities, my team had to communicate in English about these technologies. Effectively communicating with key developers was the most important thing for us in implementing the required features.
Picture 1: Mr. Eto’s biggest achievement was the Tokyo Stock Exchange system renewal in 2010. It was changed from a mainframe-based trading system to a Linux-based, Red Hat Enterprise Linux system. The response time was 1,000 times faster (down from 2 s to 2 ms). From 2015, the response time was down to 0.5 ms.
Another big discussion involved upstreaming all codes or creating a modified code inside the operating system. Historically, Fujitsu developed huge UNIX servers and modified the licensed SYSV UNIX code to drive those large servers. If we chose the same way, we had to obtain ISV certifications for each modified UNIX code. Finally, we decided to upstream all codes and work with Red Hat to distribute the Linux operating system that included our new features. Doing it this way significantly reduced the ISV certification cost, although we did still incur a large cost (in time and money) developing all the features in all the communities. It is important to note that at the beginning of development, I could not contribute any code to these developments. I used my required reporting constraints as excuses to my bosses for not contributing code. Two years later, my team was able to contribute small amounts of code.
Picture 2: In 2006, the first engineer from Mr. Eto’s team was invited to the Linux Kernel Summit. More and more engineers went to these events after the team got involved with the upstream community.
Around this time, I needed to establish a new way to measure the development effort because the current development reporting method did not reflect our goals. I tried several measurement methods to modify the traditional reporting method, but everything only explained where we were, not where we were going.
In 2005, the source management system moved to “git.” I attempted to develop my idea in shell script with git features, but the scripts were very complicated. The developer of git is Japanese, and I spoke with him directly about several features at a global event in Japan. I learned that several developmental features had to be gradually input into git, so my scripts were simplified later on. After that, I asked my manager to maintain the scripts, and he asked me to make the results public, which I did.
At some events, I overheard someone mention my website and that his boss had asked that his team put it on their Top 10 list. I enjoyed hearing that conversation!
Picture 3: This picture is from an open source event over a decade ago. Mr. Eto is on the far left of the front row and looks very happy.
Through all of these challenges, I studied a lot. I also came up with some life lessons:
- Do not seek perfection all the time
- Sometimes, “done” is better than “perfect”
- Allow for “misunderstanding” in communication
- Certain portions of our lives are created by misunderstandings and may have better results than if we had understood something perfectly
- Sometimes, misunderstandings will create better working relationships
- Conflicts among developers can create innovation
- In communities, developers working on different goals can discuss joint implementation
- Communication is the only way to solve conflicts, but some misunderstandings will always remain
- Challenges will lead to failures due to a lack of experience, but you should not be afraid to fail because that is how you learn
“Tsurezuregusa” is a collection of essays written by a Japanese monk in the 1300s. Chapter 150 discusses how we should seek challenges to gain new abilities. For example, I did not hesitate to take on the challenge of communicating in English, as this was the only way to create innovations in technology.
Picture 4: Linux Foundation Fellows Greg, Linus, and Mr. Eto at the Open Source Summit Japan 2023.
In conclusion, I would like to thank the many excellent engineers in communities and in my team, maintainers - including Andrew Morton and Greg Kroah-Hartman, and friends - including Jim Zemlin - who supported me to make my crazy dream come true.
