Luis Ibáñez works as Senior Software Engineer at Google Inc in Chicago. Opinions expressed in this site are his own.You can find him in github at: http://www.github.com/luisibanezand in twitter at: http://www.twitter.com/luisibanezHe previously worked as a Technical Leader at Kitware Inc., and Director of Open Source Community Development at the Open Source EHR Agent (OSEHRA). At Kitware he was closely involved in the development of open source software for medical imaging applications, in particular, working with the Insight Toolkit (ITK).Luis is a strong supporter of Open Access, and one of the editors of the Insight Journal, an OA Journal that enforces the verification of reproducibility. In collaboration with other instructors, Luis taught a course on Open Source Software Practices at RPI between 2007 and 2013, and also at the State University of New York at Albany between 2011 and 2014.Luis Ibáñez received a B.S. in Physics from the Universidad Industrial de Santander (Bucaramanga, Colombia) in 1989 and a M.S. in Optics from the same university in 1994. He received a D.E.A and Ph.D. degrees from the Universite de Rennes I (Rennes, France) in 1995 and 2000, respectively. In 1999, Luis Ibáñez joined the Division of Neurosurgery of the University of North Carolina at Chapel Hill and participated as a member of the MIDAG and CADDLab groups. His work at UNC was related to the development of algorithms for 2 and 3D registration applied to image guided surgery. He also participated as developer of the INSIGHT Registration and Segmentation Toolkit sponsored by the National Library of Medicine. Luis Ibáñez joined Kitware, Inc. in February 2002 where he was one of the main developers of the Insight Toolkit (ITK) coordinating its maintenance with other developers and the user community; he is also one of the main developers of the Image Guided Surgery Toolkit (IGSTK) and participated in crafting the operational principles of the Insight Journal. Luis Ibáñez is a strong supporter of Open Access, and the verification of reproducibility in scientific publications and is a regular speaker in ITK training courses, and in events disseminating the principles of Open Source. In August 2014, Luis joined Google Inc as Software Engineer, to work with the corporate engineering team in New York city.
Authored Comments
Steve,
Thanks for the insightful comment.
Your point is well taken about the differences in skills at different ages, and the fact that we tend to remember the outstanding participants and forget the rest.
Overall, when communities grow beyond certain size (I would speculate 200 developers), it becomes very important to have a diverse population, that mixes older developers with younger ones, as well a diversity of gender, nationality and educational backgrounds. That combined diversity nourishes the intellectual capacity of the community.
I would avoid stating that some of them are "better" than others, since, it is their combined diversity what makes the community function. In organic terms, we probably wouldn't say that bones are more important than muscles for an athlete. It is not much use to have ones without the other.
That being said, just to address your point: It is tricky to define what "superstars" are, but, if we suggest some quantifiable measures for the Kernel community, we can attempt to answer your question based on:
1) Number of commits contributed
2) Number of lines of code contributed
3) Number of patches reviewed
For those three questions, we can find answers in the Linux Foundation report:
http://www.linuxfoundation.org/publications/linux-foundation/who-writes-linux-2013
For example, in page 7 and 8, we find:
"The top thirty developers contributed just over 18% of the total", and the tables with the list of developer's names who will be in this top 30, if we measure since the release 2.6, or whether we measure since between 3.10 and 3.12.
Then in page 10 of the report we find the top reviewers. An interesting table that also shows how the community has become more participatory, and relying on a wider number of developers. For example, Linus Torvalds only signed-off in 0.7% of the patches, while Greg Kroah-Hartman does the most sign-off with 12.7%.
A full list of contributors can be found by using scripts that harvest data from the Git repository of the Kernel. You will find this at the end of the report, citing the “gitdm” tool, written by Jonathan Corbet: git://git.lwn.net/gitdm.git.
What we know for sure is that the Kernel can use a lot more of new and younger developers, and that there are plenty of easy patches for them to work on as they learn the ropes. Relating these new developers with more experienced developers is part of the recipe for success. This is one of the things that started to happen at LinuxCon, and probably will continue on a regular basis.
Josh,
Thanks for your comments.
Your point is the perfect transition to the follow up post where we will be describing a set of training activities that took place a couple of weeks ago at the Rensselaer Polytechnic Institute, the Rensselaer Center for Open Source (RCOS) and at the State University of New York at Albany. They were focused exactly on what you are looking for:
"How to get an easy introduction to participating in the Kernel community"
The activities were driven by an enthusiastic team from Red Hat, composed of: Matthew Whitehead and Priti Kumar.
Here is the online version of the material that we used for these training sessions:
http://www.opensourcesoftwarepractice.org/Linux-Kernel-Training-Session-I/#/
This was done with Reveal.js (which we talked about recently here: https://opensource.com/education/13/10/teaching-with-revealjs).
The source materials of these training slides are here in Github:
https://github.com/SUNY-Albany-CCI/Linux-Kernel-Training-Session-I
Note that the slides go to the right, and sometimes up / down.
The central point is that:
"It is easy to participate in the Kernel community"
and the key is to start with easy patches.
The presentation above focuses on walking you through the process.
It covers:
A) An easy introduction to Git:
http://www.opensourcesoftwarepractice.org/Linux-Kernel-Training-Session-I/#/6
(slides going downward)
B) How to get the source code
http://www.opensourcesoftwarepractice.org/Linux-Kernel-Training-Session-I/#/7
(slides going downward)
C) Quick overview of the review process:
http://www.opensourcesoftwarepractice.org/Linux-Kernel-Training-Session-I/#/8
D) Easy patches that we did with students:
http://www.opensourcesoftwarepractice.org/Linux-Kernel-Training-Session-I/#/9
E) The process of patching:
http://www.opensourcesoftwarepractice.org/Linux-Kernel-Training-Session-I/#/10
(slides going downward)
and also
F) References to other materials
http://www.opensourcesoftwarepractice.org/Linux-Kernel-Training-Session-I/#/11
In particular, you will find useful the book
Linux Kernel in a Nutshell
http://www.kroah.com/lkn/
that has a full PDF free download (at the bottom of the page):
http://files.kroah.com/lkn/lkn_pdf.tar.gz
and the sources are also in Git:
http://git2.kernel.org/git/?p=linux/kernel/git/gregkh/lkn.git.
Note that (on purpose),
the patches used in this exercise are very easy ones:
Essentially,
things like replacing "printk(...)" with "printk(KERN_DEBUG....)".
http://www.opensourcesoftwarepractice.org/Linux-Kernel-Training-Session-I/#/9/4
In this way we were able to focus on the process of submitting the patches and not worry about the software architecture of the Kernel itself.
There are thousands of these easy patches, waiting for volunteers to work on them. As Linus Torvalds put it:
http://www.opensourcesoftwarepractice.org/Linux-Kernel-Training-Session-I/#/3
"...the trivial patches are among the most important ones -
exactly because they are the "entry" patches for every new developer. ”
We did the exercise with the students using an Ubuntu 13 VM in Amazon EC2 (Using a grant that Amazon kindly provided to SUNY Albany). The setup in the VM was not fancy at all. Just needed to install several development packages. (will be glad to provide a detailed list). I can also point you to a public image of the VM if you would like to clone it.
Please give it a try at the tutorial above, and please share your feedback on what can be improved on it, to make it more accessible, and in particular: more *fun* ! :-)
The process is indeed very easy, so, if anything is confusing in the materials, it will just mean that we haven't got the content right, and therefore we have to fix it. So please don't hesitate to point out any kinks.
Thanks !