(Submitted by Marc Paré, November 5, 2012)
Kohei Yoshida is a well-known individual on the LibreOffice project. To many, he is considered as one of the core group of developers who have contributed to the steady development and code improvement of the project, and one of the leaders of the calc component. Kohei takes a little time out from his busy schedule to let us know a little more about himself and why the LibreOffice project appeals to him.
LibreOffice can only exist since people are working on it: so please, tell us a bit about yourself.
My name is Kohei Yoshida. I’m a Japanese national currently living in Raleigh, North Carolina. I used to work in the environmental science field but decided to change my profession to software engineering to make it more aligned with my passion and obsession. I’m very glad I made that switch. Now I can justify my obsession instead of apologizing for it since I’m now getting paid for it.
In what other software projects have you been involved?
Besides LibreOffice? Not much actually. Of course, I was involved in the OpenOffice.org project back in the old days, but that’s about it.
I once worked at SlickEdit as part of their development team for about one year, before I moved on to join Novell to work on OpenOffice.org full-time.
Where do you live (and/or study)?
I live in Raleigh, North Carolina.
What do you do when you’re not working on LibreOffice?
Bits and pieces of various things, such as taking my son to his Taekwondo practice, watching TV, mostly documentaries and news to learn about interesting developments around the globe, working out to stay in good shape…. that sort of stuff.
When do you usually spend time on the project?
That’s easy. Since this is my full-time job, I do it just like how other people go to work. But I also put a fair amount of personal time into it to mostly move forward some of my side projects that would not warrant using my employer’s time.
What is your preferred text editor? And why?
Unlike many other core developers who use mostly either emacs or vim, I do use SlickEdit which is a well-capable commercial code editor. It has built-in symbol database that scales very well with very large code base such as LibreOffice code base. It also has tons of other useful features that save me lots of time and effort. The fact that I used to work there developing the editor probably helped me initiate myself with the editor, and get stuck with it, so to speak.
How did you hear about LibreOffice?
Well, it’s hard not to have heard about LibreOffice as I’ve been there since day one.
Why did you get involved?
I got involved through my employer, SUSE.
What was your initial experience of contributing to LibreOffice like?
Again, this question may not apply to me personally since I was involved in LibreOffice from day one. But I think it’s worth saying that the new git-based repository made my job 100 times easier than our old system, which was basically nothing more than just a hand-crafted, custom patch management system wrapped around the upstream cvs/subversion/mercurial repos. If you are familiar with the Go-oo project, that’s what I’m talking about here.
Now that I look back, the system back then with the Go-oo project, it was terribly inefficient and not a great place to go wild with one’s creativity. I didn’t necessarily think that back in the days, but now I do.
There were rough edges even with the system we use in the LibreOffice project when we just started. But the good news is that we have since improved our system and most of the kinks are now gone. I’m very happy about that.
What have you done since then?
Well, I’ve done a lot of things since the project started. Due to the nature of my work, I tend to go to many corners of Calc, so it’s hard for me to list individual achievements. That said, overall, what I’ve done can be categorized as follows: 1) code cleanups, 2) new features and enhancements, and 3) core refactoring for better maintainability/performance/memory footprints. Recently, I’m mostly focusing on performance enhancements and core refactoring to make the code more readily extensible, easier to maintain and generally perform better. These changes are not very visible to the end users, but in my opinion just as important as more visible features.
I’ve also worked to extract some of the code into external projects, and have it maintained outside LibreOffice. Projects such as mdds and orcus are good examples of that effort.
What do you think was your most important contribution to LibreOffice so far?
The improvement in the pivot table engine, which is finally in a very good shape as of 3.6, and numerous unit test code I’ve written since inception of this project.
How will that improve things for users?
Hopefully users will have to wait less for things to get done when using pivot table. Also, having more code automatically tested by our unit test framework means less chance of having regressions. Unfortunately the coverage of our unit test framework is still not high enough, and we should still stay diligent in writing more and more test codes to accompany bug fixes. But things are improving, and hopefully as we make more releases and make more code changes (accompanied by more test code) we will increase the coverage of our unit test.
What is your vision for the future and/or what would you most like to see improved in LibreOffice?
My vision for this project is to make the code more modular; extracting more code into mdds, orcus etc to offload code maintenance, and more unit test coverage to improve the quality of the binary that we release. Of course, I can’t forget about making Calc run a lot speedier in all areas. But to achieve that goal we need to make lots of changes in lots of areas.
I would also like to someday spend some serious time tinkering with and understanding the drawing layer code. For now, I only know just a little, barely enough to get by. But some day that level of knowledge won’t be enough to carry out large scale refactoring or re-architecting of Calc’s drawing layer, which relies in large part on the common drawing layer code that all apps depend on. So, I’d like us to improve that situation one day.
The chart code is another beast that we don’t have an intimate knowledge of. Several of us have spent some time in that code, including myself, but the code still feels “foreign”. I’d like to see that changed.
Also, we really need to do something about the poor performance of ods and xlsx imports. But this is a difficult problem to solve, and while I have some ideas to improve the load performance, it’s for the long-term rather than short-term. I have some prototype ideas in orcus. The challenge is to figure out how to materialize those ideas to make them happen in LibreOffice proper. That won’t be easy, but we have to move in that direction some day.
Lastly, I’d really like to refactor Calc’s core cell storage to take advantage of newer CPU’s vectorization support, take advantage of GPU, or perhaps allow some super computer cluster to be plugged in to massively speed up formula calculations. Achieving that will be a major architectural challenge, but it’s a very interesting one.
What advise would you give new developers to make their first LibreOffice hacking steps easier?
Get a good idea of what you want to accomplish with this project, and if possible, try to establish a main area of interest, and keep forging ahead.
Anything else interesting you get up to when not hacking?
Not much, actually. I tend to spend a lot of time researching the latest on clean energy development. Too bad I can’t do much about it myself and I can only get to learn what awesome stuff other people have been doing in that area. But I do believe that we have a global-scale energy crisis, and I really appreciate those who are trying to solve this very hard problem. Meanwhile, I do my part by trying to make the application run faster which will consume less CPU power which will in turn draw less electricity and generate less excess heat.
Thanks a lot for your answers and time. We look forward to more of your great code in our favorite office suite.
