A report from JLS

Like a number of Asian countries, Japan has, in the past, had a reputation for being a great consumer of Linux: Japanese companies have been happy to make use of it when it suited them, but contributions back to Linux have been relatively scarce. The situation has changed over the years, and Japanese developers are now a significant part of our community. We get a lot of code from Japan, and, increasingly, ideas and leadership as well. Japan is pulling its weight, and, possibly, more than that.

Given this context, it makes sense that the 2009 Kernel Summit went to Tokyo. Japan (and the Linux Foundation) did a great job of hosting this high-profile event; some developers were heard to suggest that the summit should be held there every year. But one also should not overlook the significance of the first Japan Linux Symposium which followed the Summit. JLS 2009 is the beginning of what is intended to be an annual, world-class Linux gathering. Your editor's impression is that this event has gotten off to a good start.

The JLS program featured a long list of developers from Asia and beyond. Your editor will summarize a few of the talks here; others will be covered separately.

Ruby

Arguably, one important prerequisite to the creation of a thriving development community is the existence of local rock-star programmers who can serve as an inspiration to others. Japan certainly has one of those in the form of Yukihiro Matsumoto, best known as the creator of the Ruby language. He is known in Japan as an inspirational speaker, though, your editor fears, some of that inspiration was lost as the simultaneous translators worked flat-out to keep up with his fast-paced talk. Certainly the audience was clearly thrilled to have an opportunity to hear him speak.

His talk, held during the first-day keynote block, was aimed at a non-technical audience; it thus offered relatively little that would be new to LWN readers. "Matz" talked about the Unix philosophy and how it suits his way of working - "simplicity," "extensibility," and "programmability" were the keywords here. Open source was a good thing for him as well; it allowed him to play with (and learn from) a wide variety of software and set the stage for the development of Ruby. The posting of Ruby itself was a big surprise - he had bug reports and patches within hours of the creation of the mailing list. Without the open source community, Ruby would never have reached its current level of functionality or adoption.

Amusingly, Matsumoto-san noted that his objective at the outset was to create an object-oriented Perl. He did not know about Python at the time; had he stumbled across that language earlier, things might have gone much differently.

TOMOYO Linux

Security modules are among the most difficult types of code to merge into the kernel. Pathname-based access control techniques are a hard sell even by the standards of security code in general; one need only look at the fate of AppArmor to see how difficult it can be. So a first-time contributor who merges a security module using pathname-based techniques has accomplished something notable. That contributor is Toshiharu Harada, who saw TOMOYO Linux merged into 2.6.30, two years after its initial posting. Harada-san talked about his experience in a session at JLS.

Getting started with kernel development is hard, despite the existence of a lot of good documents on how to go about it. We still make mistakes. The biggest problems are simple human nature and the fact that we don't like reading documentation; these, he said, are difficult issues to patch. There is too much stuff under the kernel's documentation directory, and we would much rather go and code something than read. But there are things we should look at; he suggested HOWTO, SubmitChecklist, and CodingStyle. He also liked Linus's ManagementStyle document, which contains such un-Japanese advice as:

Linux kernel documentation, Harada-san noted, is tremendously practical.

His advice - derived from the many mistakes made in the process of getting TOMOYO Linux merged - was equally practical. Send patches, not just URLs. Stick to the coding style. Keep your patch series bisectable. Use existing data structures and APIs in the kernel. Be sure to send copies to the right people. Don't ask others to make changes for you - just make them. Try not to waste reviewers' time. And so on.

There are, he noted, lots of kernel developers who are willing to help those trying to figure out the system. Arguably the real lesson from the talk - never explicitly stated - was related to that: Harada-san was able to overcome obstacles and get his code into the kernel because he listened to the people who were trying to help him. If more developers would adopt that approach, we would have fewer failed attempts to engage with the development process.

On Japanese participation

Satoru Ueda is one of the strongest proponents of the use of - and contributions to - Linux within Sony. His efforts once led to a Sony vice-CEO asking him whether he was actually working for Panasonic, which seemed to be the beneficiary of his efforts. Ueda-san used his JLS talk to examine why Japanese developers often hesitate to work with the development community.

Is Japanese non-participation, he asked, a cultural problem? In part it might be. In general, he says, Japanese people tend to respond to strangers with fear, worrying about what unknown people might do to them. Westerners, instead, tend to be much more aware that strangers, while potentially dangerous, can also bring good things. That makes them more open to things like working in development communities.

That said, Japanese attitudes in general - and toward the open source community in particular - are changing. Japanese hesitation in this area is not really a cultural issue, set in stone; instead, getting past it is just a matter of adaptation.

Economics is also an important issue. Japanese executives are starting to see the economic advantages of open source software, and that is making them fairly excited about being a part of it. Mid-level managers are decidedly less enthusiastic; they fear that community participation could erode their power and influence within the company. They also feel stronger than the community and feel a need to keep core development competence within the company. Developers, too, are hesitant. The high visibility afforded by community participation is relatively unhelpful in Japan, where labor mobility is quite low. They fear that managers may not understand what they do, they worry about working in an unfamiliar language, and they fear being flamed in public.

Again, things seem to be getting better. Labor mobility is on the rise in Japan, and some managers are beginning to figure things out. And there are a lot of open-source developers in Japan. So, in the end, Ueda-san is optimistic about the future of Japanese participation in the development community.

Looking at how the Japan Linux Symposium went, your editor would be inclined to agree with that optimism. The event was well attended by highly-engaged developers from Japan and beyond. Questions during the talks were subdued in the Japanese fashion, but the hallway discussions were lively. JLS mirrors a growing and enthusiastic development community. This event is off to a good start; if it can retain its success next year in the absence of the Kernel Summit, it may well become one of the definitive conferences worldwide.

---

to post comments