FOSDEM 2019
Overview
After being incredibly gutted to miss FOSDEM 2018 due to my Ruptured Appendix (pun intended), I was determined to attend in 2019.
I was fortunate enough to have my employer, Capital One UK, pay to send me to the event, as they had in 2017.
But this year I felt it was quite different to previous years. Since my last time at FOSDEM, I've attended events like Hackference 2017, Hackference 2018 and DevOpsDays London 2018 where there were a number of talks directly related to the work I do, compared to FOSDEM where there was not as much to see that was directly related.
This may be partly due to the work I do now not really focussing on just the Free / Open Source software but the tooling that sits on top and the interaction with Cloud APIs. A lot of the projects and attendees there were either with the various GNU/Linux distributions or looking to i.e. be your own Cloud provider, rather than using an existing cloud.
This was quite difficult and meant that the talks I was able to attend was quite limited, so I could contribute knowledge back. I found that I was quite biased towards talks that I personally wouldn't have been as drawn to if I was coming under my own steam. That is, the talks were more "here is something I can play back to Capital One" rather than "here is something I really want to learn about".
Next time someone tells you #Java is dead, challenge them to try get into the Java room at #Fosdem
— Milen Dyankov (@milendyankov) February 2, 2019
This was especially difficult with the Java devroom being full most of the day, and there being a number of talks there that I'd have enjoyed attending both for personal and professional reasons. And with my growing interest + focus on the IndieWeb movement and the concept of decentralisation, I probably could've spent the whole of Saturday in the Decentralized Internet and Privacy devroom.
I feel that in future years, if I attend, it'll be as myself rather than through a company, unless we're really using as much of the Open Source stack that is being showcased and talked about.
Beer Event
As usual, the FOSDEM pre-event at Delirium Cafe kicked off the conference. On route, we met up with Jenny Wong, who I'd been following on Twitter for some time and Carol had mentioned on Twitter was also attending. We met up with her and some Mozzilians for some frites at Fritland.
When we got to Delirium, it was a good chance to catch up with friends I'd not seen in a couple of years, as well as for Anna to meet them, as it was her first FOSDEM, and we don't tend to see each other too much outside of it.
This was the first year I've been that they had actual beer tokens rather than beer mats, and although being much more manageable I feel strangely drawn to preferring the use of beermats.
I found that this year the music was really too loud, and it meant that it was so much harder to talk and catch up.
We also, as usual, found a too-small booth, so it was cramped and not everyone was able to sit which isn't ideal!
It was still nice to catch up and have some good Belgian beers. But a particularly bad hangover meant that the Saturday was much more difficult and less fun than it should've been - I guess there's a lesson in there, somewhere.
Can Anyone Live in Full Software Freedom Today?
just because you take a step away from software freedom, it doesn't mean that it's forever
Karen and Bradley from the Software Freedom Conservancy spoke to us about the difficulties of only ever using Free Software to remain "purists" in today's society. They noted that if we do not have Free Software, we lose autonomy over our lives, so we need to make sure we're using alternatives.
Note: There was no definition of Free Software, so we must assume that it is Free-As-In-Freedom, rather than Open Source.
Bradley spoke about starting his career in a world where all choices were proprietary, which led to him becoming disillusioned because he needed something non-proprietary to work with. But over time, with more Free Software becoming available, it's even more difficult to remain pure as there is so much more that requires binary blobs, such as the BIOS in your devices.
Karen spoke about having a defibrillator put in her body due to a hereditary heart condition. There was no option for her, it was either use a proprietary defibrillator or maybe not survive your heart stopping. This was a difficult decision, but fortunately she made the pragmatic decision to be safe and use the defibrillator.
Fast forward to having the defibrillator while she was heavily pregnant, and she was finding that she was being shocked multiple times for seemingly no reason. It turns out that her heart condition combined with the pregnancy meant that her heart rate was quite low, meaning that the defibrillator would be shocking her. As the defibrillator is primarily used in people over the age of 65, who are not pregnant, the edge case wasn't even considered as the percentages were very low. But given it was proprietary she had no way of supplying a fix that could save her (or future people) being shocked unnecessarily.
Being pragmatic in her use of a defibrillator, however, didn't really help when Karen's Dad was a really bad way in hospital, and she was struggling to get there due to only having paper maps - the realisation after this traumatic experience that she was putting her own ideals above her the ability to say goodbye to her father was being a bit ridiculous. However, she didn't change her views and disappointingly still advocated for using a paper map.
They spoke about the issue of JavaScript on websites, which by-and-large, is proprietary. We can try as hard as we want to not use proprietary applications, but the websites we use every day contain so much of it.
They commented on the fact that Firefox is the largest and most ubiquitous proprietary software delivery tool that is actually Free Software itself - woops! What's even worse is that this JavaScript is completely invisible to users and even the stringent Free-Software-only are unaware that their rights are being infringed upon. Although you may think "yeah but the JavaScript is different to downloading, installing, and running a proprietary application on my device?" and would be wrong! The JavaScript is downloaded, not installed but then runs on your device, so there's no real difference aside from not being installed at system level.
If you're interested in reading more about this, Richard Stallman (RMS) wrote a post, JavaScript Trap on the topic, as well as the project GNU LibreJS being written with this in mind.
(Note that although this site's JS is licensed under the same license that the theme is, however does not comply with LibeJS - there is a follow-up issue to comply).
Karen and Bradley also spoke about the hypocrisy of Free Software advocates who will make you feel bad for using proprietary tools, while knowing you rely on it so much - so you can buy a car, drive that car, fly to an event, or attend your doctor's clinic. They went on to say that advocates can actually be even worse than that:
Asking others to use proprietary software is as bad if not worse than using it yourself
By taking away the rights of others and i.e the advocate asking a friend to call an Uber because the advocate doesn't believe in it is even worse. By outsourcing the use of proprietary software to someone else, this is actively removing someone else's freedom and reducing their ability to make an informed decision, which is even worse than just infringing your own. The core learning is that, as a Free Software advocate, we must not take away others' rights to use Free Software, just to avoid ourselves from compromising your own ideals.
Karen and Bradley spoke about the paradox of how, the more Free and Open Source Software we have in the world, the less software freedom we actually have. This ends up being true due to the fact that there is now, in total, more software in the world. And additionally, the Free Software that is created is mostly filling certain niches, whereas proprietary software fits the other areas. Instead of creating a new project to fill a certain market, why not pick up something new?
If tomorrow all proprietary software were to now be Free / Open Source Software, we wouldn't have everything magically fixed as we still have issues like centralisation to resolve. But it would make things easier, so we need to make small choices that support software freedom.
I felt like this talk, although interesting, was quite disappointing and uninspiring, and it felt like neither of them were trying as hard as they could do. For instance, Karen would just have a paper map instead of using Google Maps. But she could use something like Open Street Maps.
They both mentioned they had really old Android devices, but as a friend mentioned, they could use the FairPhone, rather than just giving up. Alternatively, have picked a relatively newer phone and used a Free Software Android OS like PureOS or used PostMarket OS on an older device just to ensure that it's kept in date with security patches.
It was a bit of a shame that Karen and Bradley didn't have much luck living a Free Software life, but it also seemed like they had compromised on some things that they could've at least tried Free / Open Source alternatives to - whether they didn't mention it, or they just didn't try is unsure.
Keeping Track of Stateful Infrastructure
Patrick spoke about a tool created at InnoCraft to manage their stateful infrastructure in an API-driven fashion.
It seems like it was targeted more where you are either not using a Cloud / VM provider, or are using multiple that may not have similar schemas. Interesting nonetheless!
Lunch + Swag
As there was a break in the talks that I was looking to attend, Anna and I decided to head over to the various stands that were set up in the K building, and ended up having a rather expensive walk around!
Although we're used to being at events where we get given swag for free, FOSDEM isn't a conference that you pay to attend - so although they have a number of sponsors, they also operate on their donations from attendees. This is a purposeful change, as one of the organisers mentioned, saying that they like the split between sponsorship and donations.
In the last couple of months I've been rethinking how I interact with Free and Open Source Software (see blog post to come soon), and this was a great opportunity to give some money back to the projects that I use.
Not only was I in a position to buy a FOSDEM T-shirt, but I could also get a FOSDEM hoodie (for extra nerd points), as they fortunately had a couple of hoodies left in Medium sizes. We also noticed the Debian booth, and after seeing an absolutely awesome zip hoodie with an embroidered logo, I was like "I need this". As a long time Debian user, it was really nice to contribute some money towards it. Unfortunately it's a little tight so the Large would've been better - but maybe it's just a good excuse to lose some weight!
We also ended up buying some GNOME socks, as socks are cool, even though neither of us use GNOME.
Matrix in the French State
Matthew from Matrix spent some time explaining the history of Matrix, which led into the use cases of the French State.
One of the most difficult problems to solve was how to integrate Anti-Virus software into a fully end-to-end encrypted chat service. The end result (which will shortly be released into the Open Source version) is having a separate Anti-Virus software service that uses E2E encryption between the Matrix server and the Anti-Virus server, without using any users' keys but instead encrypting/decrypting with a separate set of keys.
Matthew spoke about the setup, and how government as a whole actually isn't centralised - there are ministries, schools, universities, offices, and all other forms of public office. This allows for many operationally independent deployments per branch / ministry etc, which can each have their own standards in terms of security, configuration, etc.
Matrix also needed to tweak network requests for performance, for instance reducing the amount of data actually synced between client and server.
Matthew told us how the upgrade from Python 2 to Python 3 gave them a speed boost, but didn't have any scientific numbers to hand to show what the impact was.
Matrix now has fully stable specifications as per a requirement from the French state - not wanting to be constantly shifting and worrying about breaking upgrades, they have tied down their v1.0 of the specifications. Matthew spoke about how they've gone with the plan to "first make it correct, then make it fast", which is a good idea as it saves issues around premature optimisation.
One of the most painful issues with the hard versioning of the spec was that they had with this was that they'd not baked any concept of versioning into the protocols, meaning that it was a difficult process to retrofit it - one of the biggest learnings for others, it seems.
DNS over HTTPS
The legend Daniel Stenberg spoke about DNS Over HTTPS, which he's been working on for some time.
I recommend a watch of the talk itself, as I wouldn't be able to do the subject justice.
Organisational Processes in Decentralized Software
Natacha and Zeyev discussed the way to manage a decentralised project.
They spoke about how decentralisation is usually discussed as just a technical solution to working on a project, but never in terms of the required organisational and processes that are required to make it effective.
- One complaint is that often there will be blog posts in-reply-to each other, rather than having more of a structured conversation in i.e. a Wiki or a chat / email service
- There is the issue of "hero narrative", wherein it can seem like only one person is working on the project, potentially replying to messages late at night
- If working in this way, it is common that those who do the most on the project also make the decisions. This can make it difficult to determine whether they are acting in an authoritative or an authoritarian manner, which can make it difficult for longevity of the project as it isn't as much of a group effort. Having a "Benevolent Dictator for Life" is still bad because they're a dictator"!
They spoke about applying feminist principles:
- Take care of others, preventing issues like burnout
- Share your work, make others aware of what you're doing and can share feedback
- Share your skills, so others can learn from you and you from others. It's taken for granted when you're in a co-located group, but harder when it's much more decentralised
Finally, we should realise that it's OK to use our voices, and to air political values because after all, this is most likely a political thing we're doing! We often work on tech for others, or causes bigger than us - such as the larger society, especially with decentralisation.
After not really getting involved with many decentralised projects until the IndieWeb community, it's interesting to see some of these organisational processes being practiced.
ActivityPub Panel
The ActivityPub panel was interesting to hear from a few bigger names in the community, given I've not fully looked in to how it works, just that it's a Good Thing ™.
Given my affinity with the IndieWeb and the Fediverse, it spoke to me a lot about how it enables the Social Web.
Chris, co-creator of the ActivityPub standard has just received a grant which will give him another two years to work on the resiliency of the federated and distributed social web, which will feed back into how the specifications are updated to enable long-term longevity.
It would've been more of an interesting session if I was actually more clued up on the spec and the communities, but it was still interesting nonetheless.
Intigriti: Get hacked before you get hacked!
Stijn spoke about the recent work that the EU-FOSSA working group have been doing to help manage sustainable security in Open Source software.
Stijn was from Intigriti, one of the platforms that provide the bug bounties for ethical hackers.
The first iteration was to perform some formal code + security reviews on projects like KeePass and the Apache Web Server.
The second iteration is a continuous security cycle, where they have a budget of 1 million Euros put aside for bug bounties. When raising a solution for a security finding, there is an additional bonus for having the community accept the patch, given there may be issues around performance or style of the fix that may be contentious.
An audience question highlighted that only the person raising the bug can get the bonus, which may not always happen as they may not be able to actually provide the required code fix. Unfortunately it cannot be "up for grabs" by other implementers, meaning the chance of getting that bonus is also tied into finding the bug, too. One attendee commented on how they have almost never seen a patch submitted for issues, so worries that this may not necessarily work.
This is great to see that the EU are actively funding greater visibility and auditing of incredibly key projects for both their citizens and the whole of the world. It's a great step forwards for the Free and Open Source communities as a whole, and I applaud their work!
Critical Path Analysis
Jaana spoke about how to determine the critical path for your users' journeys. It was also really cool to finally see Jaana, as I've been following her on Twitter for some time.
Jaana spoke about how when you're flying i.e. to a conference, you have no idea about all the inner workings of the various airports and airlines you're interacting with. All you know is that you get from A to B and that maybe if you're unlucky, there are some delays.
The lack of understanding in underlying systems mirrors a user's journey in our applications, where they don't need to know how everything is working behind-the-scenes, just if they can complete their user journey.
Jaana spoke about the way that by understanding the critical path of a user's journey, we can understand better how they use our systems and if there are areas we need to optimise.
However, I can also see this as a hugely important learning experience to fully understand your stack. For instance, taking a customer through a login flow to their dashboard - how many services does that interact with? What could go wrong? This can help you understand the stack much better, and be especially useful for onboarding new engineers or with closing knowledge gaps in teams.
Jaana spoke about the difficulty of coming to a large company (Google) after years at smaller companies and the amount of time required to understand the full stack, as it can be so vast.
Jaana also spoke about how we can easily track build-time dependencies i.e. which libraries a project uses, but we don't have any way easily to track the runtime dependencies i.e. services that are used. By making this critical path more visible, it helps engineers see what components are required to serve a given request, and appreciate their dependencies more.
Again, talking from the user's perspective, Jaana spoke about how the user doesn't care about what the underlying availability is of your infrastructure or "how many nines there are", but just whether they can do the thing they're using your product for. The goal should not be availability of individual components, but the availability of the whole user execution path.
Jaana also spoke about how this is even more important when moving away from a monolithic application or when you have a distributed application, as the system is now much more complicated with fragmentation of application code and infrastructure such as databases / storage. Due to this layout, a single issue (such as DNS) can become a cascading issue, and unless you fully understand the stack, it'll take lots of extra time to diagnose.
So how do we go about understanding the critical path?
- first, we need to use data from the production traffic to determine what the most common journey is
- this can be done by tracing, tracking events or parsing of logs, and then mapping that to the corresponding source code
- next, we need to make that journey (and all components of it) reliable and fast amongst all others
- finally, it needs to be more debuggable to make it easier to track down issues in the future
Jaana also spoke about how it can be difficult to get to this end goal for a number of reasons:
- it's a cross-team/cross-organisation problem, which requires coordination and buy-in
- engineers don't know where to start, which is where Jaana's steps above can give a nudge in the right direction
- instrumentation can be really expensive on your performance
- being able to tweak your systems in a dynamic capability is often underestimated and underappreciated
This is something I'm really going to look at doing, especially around the Customer Identity Service which I work on at Capital One UK. Due to it being a commercial off-the-shelf product, with a number of additions added by the team, there's a tonne of complexity there that we're always trying to find new ways to visualise and share knowledge around, especially with new members and interacting teams.
Free Open Source Corporate JavaScript Stacks
Geertjan spoke about the shift to using a Free / Open Source software solutions for browser applications. As an ex-Sun and now Oracle employee, Geertjan works on JavaScript Strategy.
Geertjan spoke about how big enterprises and corporations are now building mobile websites and engaging browser applications. This is after the changing landscape in the web as a platform, and how web has truly won the "platform wars".
Geertjan mentioned that if you were to go to an Oracle conference, you'd be seeing lots of "grey haired" people, clarifying "not that there's anything wrong with that", but with the point that the stack is a very proprietary one. In days of old, you would buy in to the Oracle stack and that would be it - which would mean if an engineer moved companies, they'd move to one using that stack.
However, that doesn't scale - especially as the population of engineers with Oracle engineering knowledge is aging, and fresh engineers wouldn't necessarily buy into it.
With the browser being everywhere, there is no point writing Java applications which then have an abstraction over the UI, to then render in the browser - we may as well just write in the browser's language - HTML + JavaScript.
Geertjan spoke about how the Oracle stack is now fully Open Source, including their tooling to bootstrap their project setup + opinionated directory structure. Geertjan went on to show us an internal only cookbook of UI components that developers could literally just drop into their project, joking that "it's copy-paste, as JavaScript developers like to do". This means that a pre-built set of components are readily available and free to use, ensuring it fits within Oracle's design guidelines.
This helps standardise also make it much easier for developers to get stuff done. But the most interesting thing is that it allows new developers to be hired in and already have experience with the frameworks being used.
This was something we saw at Capital One UK a couple of years ago, where up until then we'd been using some Capital One US-built projects, but as they were all internal-only, it was becoming a barrier to getting new hires up to speed as they'd have to learn how internally tooling worked. Instead, we now use community-standard Open Source tools like Spring Boot and React.
On the flip side, Geertjan spoke about how corporations are starting to Open Source their work, but Geertjan wants the community to be much more wary of these events. Either the corporation wants the community to provide input and to foster a community around the use of the project, or they're effectively giving up on the project, and are Open Sourcing it instead of just letting it rot in some internal repository.
With these Open Source projects, this can get people working on the company's internal tech stack before they even apply, which means they'll find it easier to apply and get up to speed once hired.
Geertjan gave the following questions to help with deciding about whether to pick up a corporation's Open Source project:
- Does their company operate in a similar way to us? Do they have similar scale, regulations?
- Does this look like a malleable/composable framework, or very vendor-focussed?
- Is the license worrying? Is there anything that could be a problem around patent claims?
- Does it fit my requirements?
- Can I instead use an existing FOSS solution?
This was an interesting talk from another big corporation and I'm sure a great insight for those attendees who haven't seen this shift in large companies recently, as they may not be shouting about it as much!
PWA Caching Strategies
Gabriele took us through some different options for caching resources within a Progressive Web Application (PWA).
As with everything, there were tradeoffs, which the talk goes into in good depth, but the very minimal TL;DW is that:
- Everyone will deal with being offline at some point, so we need to plan for it rather than make it a bad experience
- When creating a PWA, you should be considering this highly on your priorities list rather than as an afterthought, as it's a fundamental part of the user interaction model
- Depending on whether you're able to serve stale data to your users will depend on whether you go cache-first or network-first
Less painful E2E tests with Cypress.io
Pavel took us through the UI testing tool Cypress.
While starting a greenfield project, Pavel wanted to find a test tool that could be used by the development engineers as well as quality engineers, but given he was the only quality engineer in the company, he didn't want to be the bottleneck. Pavel was very explicit that there is nothing wrong with Selenium, but that instead he wanted to try something new and Cypress looked nice.
Cypress is extensible via a plugins system, for instance to allow Gherkin syntax for the browser flows. Pavel mentioned that it is easy to set up and is ready to run in an automated build pipeline, as well as having some useful debugging settings.
One feature that may be controversial is that Cypress will implicitly wait for an element to exist on the page before continuing, instead of requiring an explicit step for waiting with a given timeout.
One pro I've seen touted is the ability to provide a video of the whole user flow - especially good for debugging, but also good for manual verifications that certain steps / animations occur as expected.
One option not discussed is Protractor, which is used quite heavily at Capital One, but as I'm not that close to the UI testing side of things I unfortunately can't comment on pros or cons. One thing to note is that although it says it's for Angular apps, we're happily using it for React-based apps!
One unfortunate issue with Cypress is that it only supports Chrome which is not the only browser in the world, despite what Google would tell you, so it isn't suitable for truly covering all users.
It also unfortunately only works in a single-browser and single-tab, which means you cannot have i.e. two users messaging themselves through the UI.
It was also quite interesting to see that you can either interact directly through DOM events, or you can just send manual GET/POST requests, which can help with depending on how much you want to verify for a given scenario.
One audience question was "when do you run this" to which the answer was all the time, on Pull/Merge Request, after each deployment, and regularly against staging and production.
Another question was how long does it take to run - ten hours sequentially which caused gasps from the audience, but quickly following that with the fact that it takes 8 minutes running in parallel - a great saving in time, and really interesting speed-wise.
Hacking NodeJS applications for fun and profit
José's talk took us through the various attack vectors a NodeJS application may have, and how to look at remediating them.
The core takeaways were:
- keep on top of / notified by package vulnerabilities and Common Vulnerabilities and Exposures (CVEs)
- use well-known packages to manage anything security-conscious such as parsing user input, rather than rolling your own
- use Helmet
- check your HTTP headers with:
- use the Node GOAT project
Open Source C#, .NET, and Blazor - everywhere PLUS WebAssembly
I honestly couldn't do Scott's talk any justice by talking about it - you have to watch it, now.
His confidence in speaking, in casually working with not one, not two, but three devices for a live demo and the ease at which he made it look was exhilarating. Hilarious, smooth, and self-deprecating on Microsoft.
More #Microsoft at #fosdem! Great demos from @shanselman on the opportunities created from open sourcing #dotnetcore and an also hilarious talk pic.twitter.com/0CYbDgu2I2
— Anna (@anna_hax) February 3, 2019
Scott's talk was around the Open Sourcing of .NET Core, and then showing us just how easy it was to run on different devices.
- Scott started with a .NET Core application running on Windows
- Then he ran the same application through Mono in Ubuntu on the Windows Subsystem for Linux
- Next he ran it through Blazor with Web Assembly in the browser
- Then ran it on a Raspberry Privacy
- And finally, for extra kudos, compiled it to be run on a Microcontroller
A quick-fire, effortless journey that awed the audience. Don't take my word for it - give it a watch!
Cloud is Just another Sun
Kyle's talk was challenging the fact that we in the Free and Open Source software communities feel like "we won" the various "wars" with proprietary software vendors, but that we've actually just missed the real battle with Cloud vendors.
I would greatly recommend watching the full talk but in summary:
- The Cloud is the largest proprietary Operating System,
- It's great for convenience, as it reduces the need for engineers and systems administrators alike to even touch the Linux / FOSS software
- Will this mean we lose the skills?
- Will we be unable to move back to a world where we have to configure our network interface through i.e.
iptables? - Using things like "Serverless" will mean we won't even need to touch the OS - again, great for convenience, but poor for understanding + lock-in
- Engineers and sysadmins are turning into "API glue code writers", which is great until you need to move to another provider's API, or do something new
- We're spending so much time looking to the past that we're ignoring signs of the proprietary wars yet again
- What happens if a single provider "wins" and doesn't need to keep APIs/protocols open? Would we survive?
- Would we notice if the Linux/FOSS software was replaced with proprietary solutions?
- If it still runs the same API, we may not even notice?
- Even worse, would we even care?
- We need to recognise what vendor lock-in looks like and how we can avoid it - interestingly on Tuesday there was a discussion on Hacker News around around a 2017 blog post Vendor lockin "Lambda and serverless is one of the worst forms of proprietary lock-in". I feel like it may have been related, but it is really interesting and feeds into the discussion
This was a really eye-opening talk, and made me really think about it. It was especially useful because I wasn't around when these previous wars existed, so it was good to see the parallels and risks.
2019 - Fifty years of Unix and Linux advances
Jon "maddog" Hall took us through a 50 year journey from UNIX to Linux to GNU/Linux to where we are.
I'd recommend watching Jon give the talk.
The key takeaway is that it's up to us as Linux users to educate others, and share the reasons for why we should all be using it. There are many people who don't use it for the philosophical reasons, which is okay, but they should be aware of why it was born and why it's so important to use Free Software.
General comments
After attending FOSDEM 2016 and 2017 (and being unable to attend 2018), I think I had forgotten what to expect. After 2017 and 2018 being full of a lot of professional conferences, I was subconsciously expecting much more polished and refined talks. But as Anton Tolchanov notes below, the whole point of events like FOSDEM is for people to share their Free/Open Source projects with other likeminded people, rather than being incredibly practiced conference speakers. These were largely just engineers wanting to show some cool stuff - the titles/abstracts may not have explained as well what the talk was about, and sometimes things got a little too deep into the code. But that's okay, that's more what the conference was about.
Really enjoyed the last two days at #FOSDEM. Both the hobbyist feel of it and presenters that are very passionate (even if less experienced) are very refreshing compared to the professional speakers and ultra-polished talks that are more and more common at commercial conferences.
— Anton Tolchanov (@iamknyar) February 3, 2019
Once I remembered that this was not a "professional" conference, things were a lot better.
I found that there were so many talks that I just wasn't able to attend, due to rooms being full. This meant that I ended up missing the whole of the Free Java devroom, which I'll now have to catch up with post-conference (which slightly defeats the point of going all that way to not attend talks I wanted to!)
- Despite the rooms being full, not all the attendees were actually paying attention, which to me felt disrespectful to speakers and fellow attendees
- it was distracting seeing people writing code, or even working on their own presentations for later in the day.
- Not just being distracting
- Incredibly unfair to other attendees who'd want to turn up, and were unable to get into the room
- Also talking when the speaker was, both during the talk and during the Q&A sessions
- Attendees also didn't seem to want to be considerate to others given the space constraints - not moving their bags or coats from seats next to them, or moving into the middle if there were spaces. I realise that not everyone wants to be crammed in, but given there's issues with limited spaces in rooms, it's really unfair on people who can't find a seat in a room. That being said, the JavaScript devroom and the Community devroom were both really great at this, and it meant that every seat was filled if needbe - which didn't hold for a lot of other devrooms.
When getting to the Question and Answer sections, there were an unfortunate number of questions that started "this isn't a question, but ...". Not only does this burn into the actual time for Q&A, but it only serves to inflate the asker's ego. I feel getting more in place to stop these, as well as shutting them down, instead of letting them continue, would greatly change the dynamic.
There were a number of times that speakers went over time. Not just by a couple of minutes, but in cases where they were told they had 2 minutes left, and used another 10 minutes, and then had the audacity to ask for a little longer, and then keep going on anyway when told no. I appreciate that they have lots they want to talk about and share, and are really passionate, but it just makes it more difficult for the next speaker who has less time to get set up and psyched up, which then may cause them to run behind schedule.
Being a Brit, I'm familiar with the concept of queuing. However, it was obvious that lots of other attendees were not so accustomed to it, or maybe just didn't care. This was quite frustrating, as it would mean that I'd be patiently waiting to get into a devroom, and then would have someone just queue jump and you'd then be further at risk of not getting your seat.
It was the first year I've seen it, but having an indicator in the FOSDEM Companion Android app noting whether a devroom was OPEN / FULL made a great change and made it easier to determine if it was worth rushing half way across campus to a talk would be a good idea.
Although I feel like there was a more diverse crowd, it's still not nearly as good as in other conferences and events I attend - to the point where it was a bit shocking to see a sea of white male faces. I'm not sure whether it's the event, the community, or something else that meant that the event wasn't as diverse as I have seen other conferences and events. It is something that would be good to change in the future and to help underrepresented groups feel comfortable to attend.
I hope to be back for next year, but it may not be as an official Capital One trip, but just me and my interests.
PS - Anna has also done a great FOSDEM writeup on her blog.
Ribs!
Something I forgot to mention when I originally wrote this post was that we went to an amazing ribs place called Mozart - More than just ribs which I'd definitely recommend going to if you're in Brussels. The choice for unlimited ribs was a great decision to have, as they were incredibly good, and they just kept on bringing it.
