Developer interview: Norbert Thiébaud

This is the first in a series of developer interviews. Our hope is that these will build understanding of the growing community working to improve LibreOffice, make connections with others, and show that it is indeed possible to get stuck in and contribute to the code. Clearly the views expressed here are the un-edited views of the interviewee themselves, and not The Document Foundation, yet hopefully over time they will provide a useful flavour of the community.

We are grateful to our first interviewee whom, while being a superstar, is also a rather private person – not a social networking user or a blogger, and we respect that. Hopefully we’ll get to know him better in person at the various LibreOffice conferences of the future. He also appears to be too modest – having done some outstanding work, as an example finally removing the VOS library (deprecated for a decade) from LibreOffice, and finding and fixing various threading issues in the process. Anyhow without further fuss:

Programming is about people: so please ! tell us a bit about yourself:

I am Norbert Thiébaud (shm_get on IRC). I’m French but I live in Dallas, Texas (USA).

What was your very first program ?

Oh, that was quite some time ago… somewhere in fall 1983. I don’t remember what it was about, but I know it was in Basic AppleSoft, and it was on paper since I didn’t yet own a machine to run it. I would squat the local electronic shop to experiment with the expo model 🙂

What do you do when you’re not hacking on LibreOffice ?

I work for an ISV (Independent Software Vendor). We write tools in the Change Data Capture field: Capturing database logs ( IMS, DB2, Oracle…), moving them around, transforming them and applying to some other database), mostly on Mainframe and Unixes.

When do you usually spend time on the project ?

Usually late at night, and on week-end.

Which is your preferred text editor? And why?

Emacs, because I have 10 fingers – so Ctrl-Atl-Shift-% is not scary to me – but my brain is somehow adverse to the notion of ‘editing vs command mode’ that is at the core of vi. (and every self-respecting coder know that these are the only 2 sane choices 😉 )

How did you hear about LibreOffice ?

I stumbled on the press release announcing the creation of The Document Foundation, reading some Linux-news-aggregator
My first patch submission to the mailing list was on Tue Sep 28 18:06:49 PDT 2010. That is a few hours after the press release announcing the creation of The Document Foundation to the public 🙂

Why did you get involved ?

Well, the short answer is : Because I’ve been asked nicely.
The longer version is:
The Document Foundation presented itself with the Goal of being a meritocratic and open organization; music to my ears.
The website asked and encouraged new volunteers to step up, removing up-front a main show-stopper for me: Copyright Attribution. I have a healthy distrust of organization that claim to support open source but demand a copyright attribution, which – history has amply demonstrated – serve no practical purpose other than to allows these organizations to take the code proprietary at some point. When such organization, furthermore, is a Corporation then the conclusion is inevitable – just a question of time.
When we are talking about non-profit dedicated to free-software, there is a little less risk, but then again there are other ways: A foundation can be granted temporary stewardship by copyright owners (at their options). That would fulfill the goal of making that foundation relevant and representative, while preserving the options to rescind if things ever go wrong.

These founding principles got me interested, and furthermore the Developer page was listing a bunch of tasks from the easiest to the ‘deceptively not that easy’, that new contributors could tackle. That was very, very helpful. Being interested in helping is one thing… figuring how to get started and what to do is another, especially with such a large and complex project.

Then, after dabbling in some of these ‘easy hacks’ and posting my first patches, I found a very welcoming community, where senior developers went out of their way to help newbies like me to become productive. I was actually expecting much more hurdles. Not that everything goes, but rather than rejecting off-hand a patch, sending it back into the newbie’s lap for correction when it is not quite perfect, the whole groups was working hard to smooth the ruff angles and fixing these not-quite-up-to-par patches to make them acceptable… giving feedback along the way on how to get it better
next time.

Amazingly I found, almost despite my better judgment, that this behavior is contagious and that does not encourage people to be sloppy; On the contrary, I find it a strong motivator to be better the
next time… because you don’t want to burden the guy that will review your patch, knowing that he would spend time fixing your mess if you didn’t get it right.

So I got in, attracted by the general guiding principles that were laid out by The document Foundation, and I stayed for the rewarding and pleasant hacking environment.

What was your first contribution to LibreOffice ?

A small patch removing 5 or 6 lines of dead-code… just to get my feet wet and learn the work-flow.

What do you think was your most important contribution to LibreOffice so far ?

I mostly do Janitorial and ‘back-office’ work. Stuff that the end-users will never see or know about. Getting involved in a decade old, multimillion lines code-base is quite overwhelming. I find that these Janitorial tasks give me a path to get acquainted with the code and with the build process. These tasks tend to conduct you to all part of the code, even the part you have no idea even existed…. And there are plenty of obscure and arcane corners in such a vast project. I still have only scratched the surface.. In time I hope to build a memory map of the project overall, hopefully to a point where I can play a Jack-of-all-trade role, comfortable enough to give a hand anywhere in the code where it is needed.

What is your vision for the future and/or what would you most like to see improved ?

I strongly believe that a good house is not only nice window dressing and cozy furniture, it is also sane plumbing, wiring and solid foundations. And software is a kind of house that start as a 1 bedroom
and end-up, sometimes, as a 50 stories massive building… but that means that you’ve got to work constantly to keep the plumbing, wiring, foundations in good order and in ad-equation with the rest of the
edifice.
These problems are usually not considered ‘sexy’ problems to tackle — some pundits even warn about change in these areas as being dangerous, costly and even useless, adding some so-called ‘technical debt’ to the project — and most of the times, they only get some visibility too late: when they fail or are so out-dated and/or unmaintained that the project crawl to a stop under it’s own weight.

Ironically the very definition of ‘Technical Debt’ is indeed NOT doing all these tasks, including the ‘easy hack’ like rationalizing the types used in the code, or not using half a dozen of class to do
somewhat the same thing, or letting warnings accumulate by the thousands… And even making sure that more people can read the comments in the code, by translating it from German to English is
paying down some Technical Debt. So with the influx of new blood on the project — many of us working on these so-called ‘easy hacks’ — the result is in fact into a repayment of some of that technical debt accumulated over the past decades.

I think the biggest confusion on this topic stem from the mis-conception that LibreOffice should be considered as downstream of OOo. But one of the core reason of existence of LibreOffice, in my opinion,
is that OOo is failing its job as upstream by refusing – for non technical reason – to integrate downstream works, hence actually generating Technical Debt. I believe that LibreOffice will establish itself as the de-facto upstream, improving the product internally, innovating and cherry picking downstream or ‘sidestream’ contributions when they make technical sens. Blocking all effort to pay down the technical debt of the existing code base just to make cherry picking downstream/sidestream changes would not make sens to me.

The internal organization of the code is not the only important backstage task, there is also all the supporting infrastructures, from tinderbox to automated regression tests, from auto-documentation to a sane source-control environment, from performance regression to code coverage… all these things are a lot of works and are not visible to the end user, or the expert consultant, except that when they are done right, developers can turn around functionality much faster and in a much more reliable way.

I happen to enjoy working on these kind of problems, and I intend to do just that.