launchpadblog

Jeroen Vermeulen gives us our first Asian stop-off in the Meet the devs series.

Matthew: What do you do on the Launchpad team?

Jeroen: I work on the Translations application. That’s where we translate software (including all of Ubuntu’s “main” section!) from English into just about any language I’ve ever heard of. Many people still know it by its original name, Rosetta.

Matthew: Can we see something in Launchpad that you’ve worked on?

Jeroen: It’s a funny thing: that question makes me realize how little really “visible” stuff I’ve written. I’ve been working with the database a lot and of course fixed bugs. You could say there’s mostly things that you can’t see in Launchpad that I worked on.

Recently though I’ve been working on something you should see show up in more places soon: the inline text editor. If you have javascript enabled in your browser, you can already use the existing version when you edit a bug title. No need to click through to an editing form: you just click the “edit” icon and the title becomes editable in-place.

The version I’ve been working on together with Danilo Šegan (I found out how to type that weird letter by accident: -c S) also works for multi-line text. And of course it resizes to fit your text as you type. I had hours of fun resizing my browser window and seeing that it reacted properly.

It’s been both fun and a nuisance, since JavaScript lets you do very powerful stuff very quickly… and then it lets you spend days debugging the silliest little things. It’s a far cry from the C++ work I’ve been doing in my spare time. There, all your weak typing happens at compile time. At run time it’s all strong typing with a tiny bit of polymorphism. So it’s usually the compiler that spots the bugs, not your tests per se. As the language matured we grew habits and practices to reinforce this. Nowadays I barely even use polymorphism anymore in C++: only in a handful of isolated patterns, and more often than not purely at compile time. As my friend Kirit Sælensminde puts it, it’s great to have a compiler as a theorem prover for your code’s correctness!

Matthew: Where do you work?

Jeroen: Mostly in Bangkok, Thailand. I like to poke fun at my colleagues in places that are 40°C colder.

Matthew: What can you see from your office window?

Jeroen: One of the reasons why I picked the place: some green, unused land! It’s got grass, trees, birds, and not a whole lot of noise. That’s pretty rare in this city. What there is is usually hidden behind walls.

Right under my window there’s a dirt road with a volleyball net strung across it. Sometimes the children have to stop playing and lift the net to let a car pass underneath.

Matthew: What did you do before working at Canonical?

Jeroen: I worked for a Thai government department set up to promote open-source software in the country. It was a good chance to learn, both about technology and about cultures.

Nothing shows how the two can interact as well as the questions I got at trade shows. For instance, many people believed that software you give away cannot possibly have any value. To those people I had to explain how the software made money for the companies behind them, or they just wouldn’t consider using it. This in a country where pirated proprietary software is the norm, and price-competitive with free downloads.

Other people thought that “open source” and “linux” were the same thing, and were very sceptical when you showed them free software running on Windows. Those who do work on free software, and we have some very enthusiastic people doing that, tend to be a bit too shy for the process. They are often reluctant to badger authors about accepting patches or translations. Translating Ubuntu in Launchpad is a great way for them to get around that.

Matthew: How did you get into free software?

Jeroen: Mainly by not staying out of it. When I started programming for fun in the early 1980s, the only reasons my friends and I ever saw not to share our code were embarrassment (if the code was ugly) or fear of someone passing it off as their own (if the code was pretty). But most of the credit goes to some great people I met in and after university, and a company called Cistron that got me working with 100% free software professionally.

I did work a few jobs involving proprietary software, and some of those left a very bad taste in my mouth. At Cistron we sometimes had to patch the software we used, because it wasn’t always mature. But at least we could, and we’d be helping the software mature in the process. We didn’t need to ask for permission, or wait for someone who already had our money to decide whether our problem was a priority. In the proprietary world you always had to beg or wait for permission to solve some problem or other.

Surprisingly often, it’s easier and cheaper to deal with a problem yourself than to go through the process of getting proprietary software licenses for it. That’s even before you start handing over money. If you do make it past that, you come to the stage where you start seeing the little gaps between what you bought and what you needed. And then you end up coding your own in-house glue anyway.

There was a lot of the code as well, under the glitzy surface. Oh, the code! Some examples I’ve seen:

• A button in a user interface switches the application between two modes. The button changes its label and its colour between modes. The business logic decides which mode it’s in by looking up the button’s current colour. Yes, you read that right. This is in a large-scale financial application. The code was then given to cheaper foreign engineers for maintenance, despite all the comments, identifiers etc. being in the local language and unreadable to the engineers. The maintenance was necessary because the application relied on some proprietary commercial infrastructure that was being end-of-lifed by its vendor.
• A database table has three consecutive rows for every logical item it describes. A loop searches them linearly instead of using SQL’s WHERE clause. Instead of using a meaningful marker, the loop computes what row #i represents by taking i % 3. The switch statement has cases for 0, 1, 2, and “default.” It’s been a while but I seem to remember there was a case for 3 as well.
• A database object cache looks if the object you requested is already in memory. It does so by taking the numeric id for the object you want and comparing it to each of the cached objects’ addresses. It never finds a match because in-memory addresses simply have nothing to do with identifiers in the database. The problem goes unnoticed for years (causing memory leaks and data loss) because the compiler, also proprietary, takes until version 5.0 to start noticing that this is a very basic type error.

It’s not like we don’t make those mistakes in free software. But we let people catch us at it, and it’s better for everyone. In fact I’m convinced that projects like Linux and MySQL became so popular in part because there were enough things for beginning contributors to fix.

Matthew: What’s more important? Principle or pragmatism?

Jeroen: You’re eating soup. The bowl breaks. (Not likely, but work with me here). Now tell me which was more important: the bowl or the soup?

I know a lot of people get very worked up about this. But principle and pragmatism are on a two-way street. Going one way, principle is where you look when deciding what you should do. Or, and this is usually what gets people worked up, what everyone should do. But going the other way, you look at pragmatic reality and discern all sorts of principles. That, I think, is the real attractor to the whole debate &mash; free software has basically revived classical philosophy. What you learn there, what catches your imagination, what patterns you see and choose to explore, is all very personal.

There are people like Eric Raymond who will say that everyone just does what’s in their best interest, and nothing else will decide the course of events. The big epiphany they take from the free/open-source development is game theory and how it applies to markets. Then there are people like Richard Stallman who see how the given incentives in the market pit us against each other, and decide that it’s a bad thing. They derive a field-specific model of morality. Personally I’m fascinated by both.

But enough weaseling: I’m more on the “principle” side, because I don’t think principles are inherently non-practical. One of the smartest people I’ve known once said that morality evolves. It grows and adapts to help us survive as a group, just like perspective vision or opposable thumbs. Software licensing is at a point where different people try different things and we’re seeing what works. If I “sell” you software, it has to be like a piece of property, except copying is free and unlimited. So should we pretend that the program is still “my property” after the sale, only I’m also letting you use it? Or is it now yours, except I can sell it to others as well? It’s a lot like the old particle-or-wave debate about the nature of light.

Matthew: Do you/have you contribute(d) to any free software projects?

Jeroen: In all sorts of ways, usually to scratch an itch: a patch here, some documentation there. My main project is libpqxx, the C++ client API to PostgreSQL. I worked with the old API back in 2000, and it was as if the right approach just jumped at me, shouting “code me, code me!” I get a lot of positive feedback about how it blends in with the language and its standard library.

Sometimes you can do more good by documenting than by coding. We engineers are all the same: once you understand something, it’s “obvious” and suddenly you’re unable to explain it. I thought D-Bus was a great development when I first saw it, but the documentation was thin on concepts and too detailed. Since I had to figure out the concepts anyway, I made a list and pretty soon I had a decent introduction written up. It even sparked some debate between developers about unresolved design questions. Funny how a contribution like that is easier to make when you’re new to the project. Much the same happened with fcgi, a nice “persistent CGI handler” similar to FastCGI but much simpler.

Matthew: Tell us something really cool about Launchpad that not enough people know about.

Jeroen: My personal favourite is a very basic one that we’ve had for ages: because Launchpad mirrors subversion and CVS repositories, you can play with the code of some project and still have full revision control.

When I wanted to mess around with a piece of code I got from the internet, I used to download a tarball, unpack, work on the code, then diff against a freshly-unpacked copy. Or I’d check out the repository and never commit. But now I can just branch off Launchpad’s copy of the source tree, and commit changes locally to my own branch.

Matthew: What’s your favourite TLA?

Jeroen: Hard one, since I have over 23,000 to choose from! I keep them here.

It started out as a joke about TLA-space pollution, but some people actually use it as a reference. I do, too.

What’s my favourite TLA? I like the name of the list itself, which is a meta-TLA. GTF stands for GPL’ed TLA FAQ. If you send me a new entry you become part of the GTF Contributor Program or GCP, and you get a little logo you can show on your home page.

Matthew: Okay, Kiko‘s special question! You’re at your computer, you reach for your wallet: what are you most likely to be doing?

Jeroen:Probably checking for a 10-Baht coin so I can get a motorcycle ride back to the main road. The dogs get a little frisky sometimes, so the wild ride may be marginally safer. The coin looks just like a worn 2-euro coin at about 1/10th the price. They’re similar enough that many coin slot machines had to be recalibrated.

Matthew: Thanks Jeroen!

This entry was posted by Matthew Revell on Friday, February 27th, 2009 at 11:09 am and is filed under Meet the devs. You can follow any responses to this entry through the RSS 2.0 feed. You can leave a response, or trackback from your own site.