A report from JLS
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.