May 22, 2014
Participants: Andrew Lunn, Dan Carpenter, Greg KH, Hans Verkuil, Levente Kurusa, Li Zefan, Sebastian Hesselbarth, Stephen Hemminger, Theodore Ts'o, and Wolfram Sang.
People tagged: Andrew Lunn and Sebastian Hesselbarth.
Jason Cooper
suggested additional focus on recruiting hobbyists as a way to
improve the maintainer situation.
He suggests reaching out to newcomers, sorting out newcomer patches for
special assistance and attention, and supporting things like the
Eudyptula challenge.
Sebastian Hesselbarth
agreed, calling out good experience with a similar discussion at ELC and
suggesting hobbyists as co-maintainers.
Levente Kurusa
said that there is considerable interest in contributing, but that many
people do not know where to start, and many who do submit a patch
stop there, even those from the Eudyptula challenge.
He suggested the possibility of badges to incent them to continue.
Greg KH
said that he does not track where new contributors come from, but that
the number of contributors to the Linux kernel has been
increasing over the past eight years.
He also pointed at drivers/staging/*/TODO, and was unimpressed
with the thought of gamification, a sentiment that
Jason agreed with.
Levente Kurusa
suggested relying on self-reporting to learn where new contributors come from.
Levente agreed that the TODO files exist, but said that many people are
looking for a central TODO list or place to start.
Levante also noted that the Fedora project is using a
badge-based system.
Hans Verkuil
was not convinced that a central TODO would help, saying that posting
an email asking for work to do was often productive.
Hans also noted that there seems to be a big gap between people offering
to help on the one hand and actually doing the work on the other,
suggesting that the gap between boring newbie work and significant
contributions to core kernel code.
Hans suggests that a device driver is a good starter project.
Wolfram Sang
argued that keeping a central TODO file up to date would be highly
non-trivial, and that he would expect a newbie to be able to quickly
find all the TODO files in the tree.
Wolfram seconded the earlier suggestion of monitoring email lists, and
also suggested going through the archives and git logs to gain an
organic understanding of the subsystem in question.
Wolfram pointed at OpenWRT as a place needing newbie love.
Dan Carpenter
uses an email-based system to track TODO items, which allows him to
easily accept TODO items from others.
Li Zefan
noted that the TODO-list discussion has taken place at an
earlier Kernel Summit, with the writeup
here.
And according to
Wolfram Sang,
not much has changed since then.
Theodore Ts'o points out that mentoring is a significant time commitment, noting that Google Summer of Code suggests 6-8 hours per week on mentoring. Ted expects that only about 25% of mentees will contribute enough to make the mentor's inventment pay off, with another 25% breaking even, and the remaining 50% being a loss. Ted also points out that climbing the contribution learning curve can take several months even for full-time employees. Ted recalls starting out as a hobbyist, but also recalls putting more than 20 hours per week into that hobby, and in addition notes that the Linux kernel's learning curve has grown significantly since 1991. Wolfram Sang disagrees, arguing that although the core kernel code is much more complex than it used to be, there are plenty of drivers that are relatively easy to get up to speed on. Hans noted that people who are good programmers, are motivated, and are willing and able to spend unpaid time on kernel work are as rare as hen's teeth. Therefore, although Hans believes that mentoring is a valuable activity, he does not expect it to magically end the shortage of good maintainers.
Andrew Lunn pointed to kirkwood as a subsystem that is maintained mostly by hobbyists.
Stephen Hemminger believes that most new developers come from companies paying people to create products based on Linux. Stephen sees one challenge as being getting these corporate developers to contribute their changes, and another challenge as keeping good contributors contributing rather than going off to other projects.
Jason Cooper reiterated that he does not believe that coddling is the answer, but instead reliable detection of and response to willing first-timers.