Jean-Baptiste Kempf is the president of VideoLAN and a lead developer of the open-source media player VLC. For Behind the Code, he discusses how he initially got involved in VLC, why it was such a success, and explains why it was important for him to keep it free. He also shares his tips for developers who want to improve, and outlines what he looks for in them when he’s hiring.

VideoLAN as a student project

The VideoLAN project was started at Ecole Centrale Paris by students who were basically managing the computer network on their campus. All the computers were managed by a team of students, not the university, which was a bit unusual.

I was vice president of the network team and that’s how I got into VLC. I didn’t have any programming experience—everything was just a bit theoretical at school.

His first programming task

So the first task I actually did on VLC was very tedious and quite difficult. It was to update all the dependencies of VLC—about 100 libraries created in C and C++—to the Windows version of VLC. That’s a lot of tooling and a lot of cross-compilation—you need to know a lot about compilation, which of course I didn’t know back then, so it took me a really long time.

When a mistake becomes a genius move

One of the genius moves, which of course actually came about more by mistake than design, was that VLC plays everything you want without you needing to install any Codec packs.

Before that, it was a huge mess. You needed to double install some of the packs, which was just a nightmare. Half of them had malware in them and even debugging them didn’t ensure it would work. So then you would install another Codec pack, which would destroy the one before it.

But with VLC it just works. You don’t even need to install VLC to use it, you can just unzip it and it works.

A huge success

So VLC became a success due to a lot of factors that were independent of each other. There are some organizational reasons for this.

Firstly, we are open source and we don’t have a marketing department or a management team of people who decide on a feature that is then pushed down to the users, as has been happening with RealPlayer and BS.Player. So, when we add a feature it’s because people actually need it and actually want it.

The second reason is that it’s easy. Maybe the UI (user interface) is not beautiful but the UX (user experience) is great—just double click on a file and it will work. Whatever happens, it just works. You can play, pause, go to full screen. Then of course there are more advanced options, but for most people it works fine.

Trust us—we’ve been doing this for 15 years. We do it with no interest in making a profit and with clear goals, so people know what we are aiming to achieve and they can trust us.

For macOS users it was the only way to play DVDs for a long time. Also, you could play videos that had been downloaded, and VLC allows you to play your clip before it has read the whole file.

Keeping VLC free

Keeping VLC free and without ads is a no-brainer. I know people focus a lot on that part but, for me, it’s just the way it should be and it’s not difficult for me to keep it like that. Money can restrict you. Of course you need a decent income, but you’re programming, you’re a developer in one of the most active industries, where there is virtually no unemployment, you’re going to be earning enough no matter what city you’re based in. Sure, more money would be fun, but most of the people I know who have more money are annoying. And if it makes you a slave to your work, what good is that?

Why VLC is so attractive to contributors

Because it was done as a student project, it is a very modular program and it is very easy to add a new feature. There are about 500 modules in VLC, which means you can come and work on a very small part and improve it without breaking everything else. And that’s really helpful, because that’s how you attract a lot of contributions—VLC has received input from more than 800 authors since the beginning of the project.

Maintainability over everything

For a patch to get accepted, it needs to be maintainable as well as useful. You might be wondering why that is. Well, if you send me a patch or 2, it’s highly likely that in 6 months you’ve disappeared from the project. People change jobs, change wives, have kids, accidents, and so on. So everything in VLC needs to be done so that we can continue without you.

Which means that we put a lot of emphasis on quality. So, with any code we get sent, we need to make sure that we can still maintain it in 6 months, 1 year, or 2 years… And that’s why we have a lot of features in VLC that some consider completely useless and why we don’t have others that some people think are important. It’s not because we’re stupid, it’s just that the code needs to be clean—if it’s not, you don’t get in.

Learn how computers work

So many developers don’t know how a computer works. Understanding computer architecture is extremely important, yet less than 1% of the people I see for interview know about their computers. If your focus is a high-level language, you still need to understand lower-level ones.

My advice usually is that you should at least know C, along with Python, Ruby, or Go, JavaScript, and a functional programming. You don’t need to master a lower-level language, but you should at least understand how it works, because it will then help you with other languages.

There are a lot of “developers” who are actually technicians of one framework in one specific language. But that’s no good, because what are you going to do in 2 or 3 years’ time? To be a good developer, you need to understand the lower-level languages as well as your own.

How to recruit the best developers

Pure code testing is not the best method. It has a lot of bias and I don’t like that. For VLC I need people with creativity and who can think outside the box, and you don’t get to see that by code testing. The questions I ask in technical interviews are very generic. I’m never going to ask how you would copy a string by removing the backslash, for example. That’s something anyone can learn.

So my questions are very generic, because if you start answering them, it shows that you’ve been looking at the subject for a long time and you like it. For example, when I see JavaScript developers, I ask them questions about the HTTP stack. A lot of them are just like, “Yeah, but I don’t really know about networking.” My reaction to that is, “You don’t know about networking, yet most of your time is spent on the web, over a network.” No matter how good you are at your main focus, this makes you an average developer, and I need good developers.

Good developers are the ones who, when they look at JavaScript, go to Wikipedia, click on “web”, and the first link is about HTTP, which tells them about what a networking stack is. I don’t need them to understand all of it, but I want them to at least be interested enough in their work that they’re going to spend some time doing that. And that’s how you find good developers.

This article is part of Behind the Code, the media for developers, by developers. Discover more articles and videos by visiting Behind the Code!

Want to contribute? Get published!

Follow us on Twitter to stay tuned!

Illustration by WTTJ