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
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.
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
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
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
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
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:
Most people are idiots, and being a manager means you'll have to
deal with it, and perhaps more importantly, that _they_ have to
deal with _you_.
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
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
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)