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
Victoria,
Thanks for the great article.
Internationalization and localization are indeed a very important topics, that unfortunately are sometimes disregarded by many projects. It is great to see them addressed in OpenStack.
These are the kind of features that are easy to implement, when thought from the beginning, and that it are very hard to fix as an afterthought.
They are also critical for triggering wide adoption since adopters would, of course, prefer to use the software in their native language, if it is available.
As you pointed out, this goes beyond the language translation, and involves adaptation to the idiosyncrasies of particular cultures.
This is a great reminder of how important is to honor the international nature of open source communities, by recognizing that adopters will also have different cultures.
Amye,
Thanks for the great article.
For the longest time, we developers, have look at documentation as the "vegetables" of our programming lunch... We know they are good for us...but... :-)
Of course, when it comes to trying to use someone else's code, we do expect documentation to be up to standards, and get quite disappointed when it is not.
The degree of documentation is one of the good metrics that Ohloh publishes in the project factoids. Typically a 20% fraction of comments is a good sign. That is 20 lines of comments per 100 lines of code.
http://www.ohloh.net/p/itk/factoids#FactoidCommentsHigh
Curiously, documentation is one of the areas where projects can use the help of beginners and newcomers. The rationale is that: if beginners get lost and confused, then our documentation is not good enough. Creating the mechanisms for newcomers to point out flaws and misses in the documentation is a great way to open that dialog and feedback.
Here is an example of what we did in the Insight Toolkit (ITK). Where we use Doxygen (a great documentation tool) to harvest documentation from comments embedded in our C++ code. As part of the web generated pages we added a PHP infrastructure to enable readers to point out flaws in the documentation and to submit them as Gerrit patches, that can right away be code-reviewed, and potentially committed into our ITK Git repository.
Here is an example for the class Array2D:
http://www.itk.org/Doxygen/html/classitk_1_1Array2D.html
and the page where a reader could generate a documentation patch:
http://www.itk.org/editdoc/editcomments.php?file=itkArray2D.h
that will go automatically to the Gerrit review system
http://review.source.kitware.com/#/q/status:open+project:ITK,n,z
The contributor gets full credit for her/his authorship, and everybody wins.
This of course, only covers the technology of the collaboration platform, and must be accompanied by nurturing in the community a culture of:
"Leave the place cleaner than you found it" :-)
Thanks