Fosdem 2013 Impressions

 Version française disponible

As promised in my previous post, here is an overview of the Fosdem 2013 conference (Free and Open source Software Developers’ European Meeting). As Sunday is the holy laundry day for me and also the best day to recover after a full week, you will understand why my report is limited to Saturday only.

The conference takes place at the ULB (Université Libre de Bruxelles) campus. For one day, I feel younger and go back to college, which are very similar to French ones with dilapidated buildings and very nice brown/green decoration… At least some decades ago.

Fosdem Opening

I arrive just in time for the opening keynote, there are already a lot of people in this big auditorium and I am not surprised to see that I’m surrounding by men.

Fosdem Opening keynote

After an introductory speech, the Fosdem staff does not forget to introduce the video team and finish by some… dance steps! While the audience is invited to come on stage to participate in the choreography (I was not able to dance as I was taking pictures). This is the traditional “Fosdem Dance” that takes place every year. The dance is completed over the years with new moves if I understood well. You can watch the video. Sometimes I wonder what the organization has smoked! But it’s fresh and it’s goodwill, we love and who knows? Perhaps it will be the latest trendy dance after Ganma Style and Harlem Shaker.

Fosdem Dance

The Jenkins community

In the same room, I continue with Kohsuke Kawaguchi’s keynote, the creator of Jenkins. I take the opportunity that some people are leaving to get closer to the stage. Actually, this is the main reason of my coming to Fosdem. After several years of using his continuous integration platform, I really wanted to see him.

His presentation focused on the Jenkins community with an intriguing title: how to collaborate without communication? Ultimately, this is what happens with Jenkins: hundreds of plugins, thousands of committers, for a successful software still widely used and rising. Kohsuke reveals his recipe for the magic potion.

Jenkins keynote

There are two key ingredients: scalability and modularity. These ingredients have a cost in terms of development, but the return on investment is high. And regarding the success of Jenkins, we cannot disagree.

Scalability:

• Give the “power” to plugins
• Be able to do recursive extension (i.e. possibility to create plugins of plugins)
• The Core of Jenkins itself is a set of “hidden” plugins
• There are currently more than 600 plugins available

To give you an idea, here is the list of extension points of the Jenkins Core. Kohsuke did not lie to us!

Modularity:

• Provide a clear and well-documented API
• Implement the concept of Silo. A committer will always work on small portions of code. Working on 5 or 500 files will be completely different in terms of complexity
• With Silos, we understand that the Core does not contain everything.

Scalability and modularity improve the readability, flexibility and stability of your application. Software become easier to use and extend.

After the ingredients, let’s talk about chefs. In fact, you, me, everyone can become a chef committer on Jenkins (Kohsuke jokes by telling us that there is an IRC bot that handle the creation of accounts). It is at the opposite direction of the Linux kernel policy where Linus Torvalds will always be the last person to validate and commit your changes (I’m exaggerating a bit, but it is something quite similar). That’s not to say that it is the complete anarchy on Jenkins! In the worst case scenario, if you break something, the scope is narrow (limited to one plugin). In addition, there is always the possibility to rollback your code to the previous revision. According to Kohsuke, there are very few cases because people are very careful when they have the “power” in their hands.

Let’s abandon the cooking world and let’s enter into space. What is the center of gravity of Jenkins, the little thing that makes sure the application will not collapse? Answer: communication. There are different ways of communicating: IRC, meetups, hackathons, events, twitter, blog, wiki, conferences. However, this communication is deliberately restricted in the sense that it is limited to specific groups organized by plugin. There are many committers, yes, but they don’t speak to each other a lot. Remember the old adage: No need to write documentation, the code speaks for itself! It’s a bit of that here. When there is too much discussion, the useful information is drowned in this huge stream of messages, and it quickly becomes chaos or black hole to continue our metaphor.

Let’s continue the relationship with the solar system, the Core of Jenkins is the sun and the planets are the plugins that gravitate around. The Update Center is the keystone of the sun. Thankfully, in the case of Jenkins, it is not an explosive one but a graphical interface that allows users to manage dynamically their list of plugins.

A final aspect of Jenkins that you may notice: self-reinforcing.
More plugins attract more users. More users supply a more active collaboration (more ideas, more needs, more committers). Thus it allows more committers to develop more plugins. And the circle is complete!

In conclusion, Kohsuke reminds us the watchword of his presentation: scalability, and also 3 elements you have to consider constantly:

• Reduce the scope of developments
• Reduce communication
• Let people innovate

This first keynote was very interesting, I’m not disappointed at all! I still have some time before lunch, I decide to assist a presentation about the use of personas. This time, the format is short: 40 minutes, questions/answers included. Presentations are time-boxed in order to leave the room on time for the following session.

Using personas

I find myself in a classroom, I can find a pretty good place (disturbing at the same time some geeks with their Linux-boosted laptops). By the way, I could not help but smile when I saw Ubuntu booting on a Macbook.

Anyway, let’s go back to the main topic. Personas are fictional characters. However, they should be detailed enough to be real (a name, a photo, age, job and interests). It is a kind of profile.

Personas are the target audience of your application, they represent the users. They help by bringing debates and discussions within the team.

What are the steps to create a persona?

• Conduct interviews and surveys of your users’ population
• Make clusters to identify common characteristics (grouping together a sub-population)
• Simplify groups to form archetypes

Be careful of the pitfalls, it is important to avoid caricature.

Personas help you to know your users better by personifying them and, as ultimate goal, to know your application better, in the sense of expected features.

Main benefits:

• Better know users’ expectation
• Happy users

End of presentation, I am a bit skeptical, but now it is time to eat. As I’m living in Belgium, I decide to avoid French fries, which allows me to escape the queue, classic triangular sandwiches will do. At the same time, I meet Tugdual Grall who now works at Couchbase. It is always a pleasure to talk about Nantes and take some fresh news!

We agree about the fact that this conference is oriented low-level development. I guess you won’t feel it by reading this report, as I carefully chose my program. Here are some sessions I could have chosen:

• ARM support in the Linux kernel
• Open ARM GPU drivers
• Introduction to C++11 and its use inside Qt
• A Continuous Packaging Pipeline
• Bootstrapping Debian-based distributions for new architectures

This is a little bit (a lot) too technical for me. I use Ubuntu but most of the time I never open a terminal. By the way, if you use Ubuntu and Gnome Shell, here is the tutorial to customize your interface like mine. The fact of patching the kernel or get a kernel panic is scaring me like the title of these talks! About Kernel panic, actually I had this message once after updating of kernel version, which forced me to reinstall everything, needless to say I was a happy user.

Let’s avoid these compilo-assembler talks, we decide to assist to the presentation about the testing of MediaWiki. MediaWiki, you know? This is the wiki platform used by Wikipedia.

How MediaWiki project is tested?

The MediaWiki team uses Watir for the user interface automated testing, and more exactly Watir web driver which is based on Selenium. Some years ago, I wrote an article on Watin (a derivative of Watir). Watin is used with .NET, Watir with Ruby. Wat is the acronym for Web Application Testing.

MediaWiki Talk

In short, it allows you to run commands from your terminal and interact directly with your browser. You can search on Google without using your mouse… Awesome, isn’t it? Well OK, this not very useful in everyday life, but in the context of continuous integration, this is good. In addition, they use Jenkins!

They have different builds in Jenkins, one per targeted platform and browser (Chrome, Firefox, IE 6, 7, 8, 9, Android, iPad, iPhone). Just before, I had seen Kohsuke in the room, maybe he has a 6th sense to find topics that involve his platform!

The MediaWiki team has written a set of scripts corresponding to high-level scenarios. We’re a bit in the BDD world (Behavior Driven Development), the speaker takes the opportunity to talk about Cucumber. Then, he did a demo of the user login testing scenario. If a user is administrator, he/she can access additional buttons dedicated to administrative tasks. No demo effect, it works, the script has been tested and retested, for sure.

This talk reminds me one of my own experience with Selenium I had in my previous company. The experience wasn’t so good and I am not very convincing by this kind of testing. We always had failing tests due to timeouts or some other unknown reasons, while the same tests were passing the day before. At the end, we do not even look at them, even if they could indicate the presence of a defect. In addition, as soon as you modify the application (CSS, html structure of webpages), you have to review GUI tests, this process is very time consuming.

But the MediaWiki case is slightly different. The application is very stable in terms of functionality. To simplify, you will always have several profiles of user that will write articles. The application will not be deeply redesigned overnight. The application is lightweight and simple in the sense that you do not have complex and asynchronous processing like AJAX (it’s always hard to test). There are themes and tests are performed on the default theme. It will not change overtime because this is the final goal of the themes module. All that to say that there are minor impacts in MediaWiki concerning GUI testing.

Finally, I attend a last talk, which I have to admit, literally killed me. The title “Should we embrace the App Store?” seemed attractive, but the fact that it was part of the legal issues track should have aroused my suspicions. It did not.

Should we embrace App Stores?

No slides, 2 speakers, 1-hour of English discussion on App Stores and legal issues. I should have run away, but I was placed in front of the speakers, um, I stayed per respect for them. Some keywords that I have scribbled before losing consciousness: Copyleft, GPL License V2-3, Warrantly…

You have understood, I do not have enough material to make a summary of this subject. At least, it makes me think of an article I read some time ago, about App Stores. The fact that in the future, you will earn more money by distributing applications than by developing them. Apple has understood it by charging a fixed-percentage fee on each application sold and available on its App Store, Google does the same with Google Play. And it can be generalized to other media such as music with the Apple iTunes platform. This is something you have to think about.

One last tour before leaving…

Before leaving, I gather my strength to walk around in the stands area.

Part of the open source stands

Fosdem is an open-source conference, this is the reason why there are stands for Linux distributions such as Ubuntu, Debian, OpenSuse, but also Firefox, Gnome, KDE, and so on. In passing, I pick up some goodies, especially stickers…

My stickers collection from Fosdem

I also pass by the stand of Open Street Maps, the open source cartography. I wrote an article some time ago. As I sometimes add fuel to the fire, I started a little discussion OSM vs Google Maps.

OSM stand

Finally, apart from the App Store talk, the day has passed quickly. And I’m really glad I attended this conference, moreover free and open to all. I rather regret not being able to go on Sunday. I missed the presentation of Tug on Couchbase, a session on serious games and other NoSQL talks.

Make the appointment for February 2014 to learn some new steps of the Fosdem Dance (among other things)!