By Gilles Dubuc, Wikimedia Performance Team
FOSDEM is the biggest Free and Open Source software conference in the world. It takes place in Brussels every year, is free to attend, and attracts more than 8000 attendees. Aside from the main track, FOSDEM is made of developer rooms, or devrooms, self-organized conference tracks. For FOSDEM 2020, the Wikimedia Performance Team decided to organize a Web Performance devroom. We wanted to share our experience here, to give people an idea of what organizing a track at FOSDEM is like.
Why did we organize a Web Performance devroom at FOSDEM?
There are industry conferences solely focused on the topic of web performance, such as We Love Speed, perfmatters or performance.now(), in addition to tracks and talks at broader interest conferences. Having attended many of them and spoken at some of them, we noticed that some topics were underrepresented.
For instance, academic research on this subject seems to exist in an entirely different realm, with talks about web performance research only happening at academic research conferences. Another frequently missing topic in industry conferences is free software and open standards. All three of these areas provide the backbone for what makes web performance a field, but best practices talks tend to dominate conferences.
For some time our team discussed organizing our own web performance conference that would cover these underrepresented topics. However, the logistics of fully organizing a conference seemed daunting for our small team.
A FOSDEM devroom seemed like a great compromise for us. Most of the logistics of organizing a conference would be handled by FOSDEM, and it would allow us to focus on the content of our track.
Applying for a FOSDEM devroom
We set out to pitch the creation of a new devroom focused on web performance. Most existing devrooms happen every year at FOSDEM, and because there is limited space, it can be challenging for a new devroom to be selected. Applications usually open in August with an announcement on the FOSDEM website and their mailing lists. You have about one month to apply, and selected devrooms are announced about 10 days after the deadline.
We applied. We were selected and given half a day. FOSDEM happens over the course of 2 days, and different devrooms get different durations.
Selecting talks and putting together a schedule
Devrooms are free to set up their own schedule within the allocated time frame. They are truly self-organized. Our first choice was to dedicate the half-day we were given to talks only. Half a day didn’t seem like enough time to run both talks and workshops in a meaningful way.
To select our speakers and talks, we decided to have an open call for participation for people to submit talk proposals. Our Call for Proposals (CfP) announcement was then posted on the FOSDEM website and their mailing list. We also advertised it on other mediums like Twitter, where the web performance community is quite active.
Our CfP encouraged people to submit their talk proposals on the FOSDEM website directly. In hindsight, we should probably have collected talk proposals ourselves on a different platform. Pentabarf, FOSDEM’s web-based event management software, has very dated UX with many steps required to submit talk proposals. We might have received fewer submissions than we could have because of it.
The schedule to gather speakers and talks is quite tight. We were able to open our CfP in early October, and we had exactly 2 months to select the final list of speakers and talks.
We received a lot more applications than available slots, but a fair amount of applicants didn’t follow the requested topics on our CfP. In the end, making the selection was fairly straightforward. And on that part, Pentabarf made it quite simple, thanks to its built-in voting functionality.
Since FOSDEM is free to attend, FOSDEM doesn’t have money to sponsor speaker travel. This proved to be a blocker for some of our applicants, and in the end, we were able to afford sponsoring one of our speakers to come to our devroom.
This is something we will plan better next time in order to be able to help more speakers with travel costs if needed. A strategy other devrooms have used is to find local businesses in Brussels that would be interested in hiring speakers as contractors around the time of FOSDEM for in-house training and similar services. The local company would then cover the speaker’s travel cost.
There are probably other ways to fund this part of the event, but it’s critical to plan that part early, as some speakers simply cannot afford to travel to Brussels, especially those who are self-employed.
Aside from travel costs, we also had some back-and-forth with speakers that needed to adjust their talk contents to match our devroom focus. These discussions were always constructive, and we learned this way that potential speakers who might have submitted a talk proposal that looked off-topic to us sometimes had an on-topic talk up their sleeve. It was worth having that discussion rather than rejecting them directly.
Once all the final talk proposals were selected and polished and a schedule agreed upon with everyone, we submitted it all to FOSDEM, and a week later it was posted officially on their website.
Now, after that official announcement, the FOSDEM schedule for the devroom remains updatable until the event itself, which would have allowed us to substitute speakers if one had to cancel their participation, etc. Any update to the schedule, talks or speakers from our devroom admin accounts is reflected on the FOSDEM website in a matter of minutes. This sort of flexibility is very powerful and often missing at other conferences.
Announcing our lineup
It can be difficult to get visibility for your devroom on the FOSDEM website, as there are dozens of them. It can also be challenging to advertise what is essentially a mini-conference inside a bigger one with a very broad theme.
We took care to announce each speaker individually, which helped get visibility from their own networks. With our devroom being new, we were worried that it might be challenging to attract people to it, who might have their habits at FOSDEM, visiting other devrooms.
We also built a dedicated website for the devroom, as the page that was automatically generated on the FOSDEM website felt a bit generic. Our devroom website proved useful later as a more attractive place to post the recorded talks after the event.
And finally, the big day! Since our devroom was only half a day, there was another one in the same room before us, the DNS devroom. When we showed up during that previous one, the room was quite full, but we were still worried that it might empty completely when the first half of the day ended and our devroom started.
After picking up our highly visible devroom shirts, we discovered the well-oiled logistics when we showed up in the room during the small break. Different microphones and a video camera were all already set up and ready to go. All we had to do was have each of our speakers test that their laptop worked correctly on the A/V system, which took a few minutes.
We also saw that it was really useful to have at least 3 of us present in the room. One person to introduce the speakers and pass a microphone to members of the audience for questions and to keep speakers on time with the schedule, one person to drive the camera choices of the live video stream (basically alternating between a view of the computer screen, the speaker, or both whenever we like), and finally someone to keep people from stepping in front of the video camera or knocking it over…
At FOSDEM video staff are shared by the entire floor, which means that the video camera stands on a tripod unattended. If adjustments need to be made to the camera’s focus or framing, we send a request via instant messaging to the FOSDEM volunteer video staff, and they show up in a matter of minutes to take care of the change or issue at hand. This all works great, but our devroom turned out to be so popular that the dozens of people standing at the back would often get dangerously close to the camera. It was useful to have someone near it to remind people of its presence.
A nice addition would have been a fourth person to act as a photographer, with a proper camera and to handle live tweeting/online interactions. We took the pictures as best we could with our phones, but with no natural light in the room, the photos weren’t great. Same for online interactions, we all did our best, but we were quite distracted by our respective higher priority roles in the room. This is why we think that you need at least four people in a FOSDEM devroom to run it at the same level of quality as other comparable conferences.
The turnaround for the FOSDEM staff to produce the talk videos was incredible! The devroom wasn’t over yet, and we were already receiving videos to review for the first talks. FOSDEM then provides a web-based tool that allows you to pick the exact start and end point of the video, verify sound, etc. It was very efficient to use and in a matter of minutes each talk video was edited. A few hours later – the evening after the devroom – the talk videos were online already!
Some of the speakers reposted the videos on other platforms that track views, while the hosting FOSDEM provides by default (and that we use on the devroom website) doesn’t record viewership statistics. That would be a nice addition, as it would allow us to see which talks were the most popular after the fact, in order to adjust our talk selection next time.
Overall the experience of running our own FOSDEM devroom was everything we hoped for and more. It was superior to other conferences in many ways. The high-quality live streaming and same-day final videos were amazing. The audience in the room was bigger than some dedicated web performance conferences we’ve been to, which made our speakers very happy. We look forward to applying again next year, for a second edition of the Web Performance devroom!
About this post
Featured image credit: Courtesy Peter Hedenskog