Over this last weekend, I attended my first OggCamp. The weekend was best described by the phrase Collaborative Culture, coined by Jon, and from their Twitter description "Free Culture, Free and Open Source Software, hardware hacking, digital rights, and all aspects of collaborative culture".

I wasn't quite sure what to expect, but I thought it may be somewhat like FOSDEM, but on a smaller scale. It had similarities, but you could definitely feel it was a lot smaller, which in itself was very different to other conferences I've been to in the past. It was a very varied conference in levels of technicality and of talk topics, not least due to design of having 2/3 of the talks in Unconference format.

It was also pretty cool that the Open Source Initiative sent through some cupcakes!

Day 1

Welcome Speech

Starting off the day with WiFi passwords, safety details, and a great big welcome, Jon didn't waste any words, as he wanted to make sure we all had time to get Unconference talks up on the boards, and give people time to decide what they wanted to attend.

I had a few minutes to prepare with the audio/visual connectivity before I kicked off the conference's main stage talks! There were at least fifty people who wanted to learn about Configuration Management using Chef, which was really exciting as it was easily the largest group I've presented to. A good 2/3 of them were familiar with Configuration Management, but not with Chef, so I hope I shared some good insight and some of the reasons why you'd want to adopt it as your tool of choice.

I was still chopping-and-changing my talk the night before, but as soon as I'd got my laptop connected, I was feeling pretty comfortable and ready to drop some knowledge. Something which initially threw me off, but I hope I recovered from, was not having a microphone - I only realised when I was starting to introduce the talk that I didn't have a microphone at the podium. Not wanting to lose any time on the strict 25 minute slot, I tried to project my voice a little better, which I hope I was able to do well enough - I didn't hear any complaints at least.

I didn't need to refer to my notes, and I felt that the talk actually went pretty well aside from being a little rushed towards the end. The rush towards the end was mainly due to me spending too much time on the "what is config management" section, which I feel I should've glossed over due to the audience saying they were pretty comfortable with the term. I also definitely didn't need each of the kitchen commands to be run through, when instead we went through the full lifecycle of kitchen test. I'll likely move them to an appendix of sorts, rather than being in the main slides.

I'd been asked a question about my use case differences between Ansible and Chef, which I mention in the talk - the main one being testing, but also having a source of truth in a separate place than Git, i.e. a Chef server, to which another audience member mentioned that Ansible Tower can fill that role.

I'd also been sent a box of swag from Chef, which went down a treat, and only had a few morsels left after the talk, which I then moved to the main reception area.

I also found it pretty cool that @computa_mike was given a new spark of inspiration to get started again with Chef after my talk:

I've been playing with @chef last week - and I had gotten somewhat disheartened - but seeing @JamieTanna 's chef talk left me all inspired again. particularly about params. Wondering about a standard recipe for deploying a website onto a server. Man I love going to #oggcamp

Jeroen took us through his work with emulating mainframes using Hercules 390. With no experience of how mainframes work, there was a lot of new content and it was quite cool to see how one would write and execute code for a mainframe. Jeroen shared how he works in the not-so-thriving community and how he's struggled with inactive maintainers of software, and very few picking up the mantle.

The difficulty of maintaining Open Source - what happens if you move on from a project, but don't officially announce it? Jeroen Baten shares his struggles with finding support for Hercules 390 #oggcamp

Antonio took us through his tips for how to get started with conference speaking.

One observation he made was how although many conferences mention that their Call For Papers / Call for Proposals process may be touted as "anonymous", often it may not be as you may be asked for supporting information such as previous talks which will inadvertently identify yourself.

To get an edge against all the other proposals going in for a conference, Antonio recommended that if it's possible, you should try to target your proposal to the conference's themes, so it doesn't sound like a generic re-posting of your talk, as well as making sure you don't submit a talk that doesn't fit in with the theme of the conference.

He mentioned that after speaking at local meetups and gaining confidence, applying for a conference in eastern Europe is a great way to get a name for yourself. In his experience, they will be more willing to pay for travel/accommodation and it's great marketing for them to have speakers from various areas. And when you're looking to go for a larger conference it could require planning a year ahead in - as he says, it's a marathon, not a sprint!

One of Antonio's strongest points was the act of getting feedback on the talk both before and after the CFP process, be it successful or not. I'd add on this that it helps to share around your talk abstracts with your peers, both those who will and won't know the topic well - if you don't think about your audience and the chance they won't be subject matter experts, you won't be able to sell it correctly. You need to ensure you're getting continual, incremental feedback to polish your talk.

There was a question about oversaturation, which linked into a comment about questioning why you want to speak. For me, it's because I just want to share my knowledge a la blogumentation. Although I enjoy building up a personal brand, I'm more excited by the ability to share and learn from others. I find blogging a great way to get started, but being up on stage and having some dedicated time to get my passion and knowledge across can be much more effective than just reading some written words. This oversaturation of talks also makes it hard to get your foot in the door, as there could be i.e. 10 other talks about Configuration Management at a conference. Having a different angle for your talk makes it more interesting than a generic talk, and helps give your audience something new to learn, even if they're already quite knowledgeable on the topic.

Although it sounds like common sense, I've definitely fallen prey to not practicing the talk out loud in the past. As Antonio put it, "when you perform the talk in your head, it's always the best talk you've ever done" - by speaking out loud, you'll get used to saying the words, you'll make mistakes that you can then improve, and find sentences and phrases that don't quite work.

And finally, there was the talk of rejection - it'll happen, but if you can get feedback on why, then you'll be in a better place for the next one.

Lightning Talks

Unfortunately a speaker dropped out last minute, which meant that there was a slot of lightning talks, with a great variety of talks. I'd have found a couple of lightning talk sessions interesting, as there was already a great range of talks, and think that if it was planned into the event, more attendees may have been interested. I definitely would've been up for talking about other, shorter, topics if I'd had the chance.

UPS Canary

Mark talked about having a device on the network which would warn when power has switched from mains to the UPS, allowing devices to cleanly shut down. Although not an issue I face currently, I can see it working!

Things I learned kid-wrangling at Hacker Con

Tanya talked us through the awesome work she does to look after kids at conferences such as SteelCon, allowing parents and guardians to attend events.

She spoke about how, unlike with adults, you can't just get children to sit on their phones if they're not interested in the activities, but instead have to provide many alternative activities.

She also mentioned the various organising issues, such as labelling / counting children so you don't lose them, ensuring that Criminal Record Bureau checks are done, and that no matter how low your patience, you stay calm around them.

Are LUG and small events even relevant any more?

Sebastian spoke about how Linux User Groups are no longer much of a thing, he believes because it mostly "just works" so there is less tech support needed. There's a lot of time, money and effort that can be expended to set up a usergroup for very little gain, when coming to a larger event may be more rewarding.

Google isn't sure this building exists

What weird things are there on Google Maps? Are they staged, or is it just "day in a life"? We visited some of Jon Rafman's blog 9 Eyes which explores some wacky events from around the globe.

PiDP8/I

This was quite an interesting talk about the PiDP-8/I, a project to help retain computing history by turning a Raspberry Pi into a functioning PDP8/I emulator.

This session was a live recording for a podcast, containing a few people that I've only ever heard, not seen, so it was quite a cool experience.

There were two main questions the group were concerned with:

Are we doing enough for collaborative culture?

Where do we rationalise the choice for proprietary software?

Around collaborative culture, there's the worry that at events like OggCamp we're preaching to the converted - likely those attending these events will already be bought into the concepts. We need to get out into other groups and spread awareness of the alternatives to the monopolies.

It was mentioned a few times by either the cast or the audience that they worked "for the man", and that they were "forced" to use proprietary tools, to which the response was "No you're not forced to use them. You can leave whenever you want". By all means can we be masters of our own destiny, but as one audience member rebutted, the company they worked for had recently started to realise that Free/Open Source solutions were an option, and that if there weren't those of us who remained to help guide the conversation, we'll never be able to make the difference.

The Performing Rights Society is in charge of chasing licensing royalties and they teach young artists they need to restrict their works, perpetuating bad habits. It'd be great if we could convince more to share their works, but how? There didn't seem to be a decision for how best to approach this.

Another point raised was that podcasts are technically All Rights Reserved as they don't explicitly license themselves differently. But if they were Creative Commons licensed, would that give anyone anything? Would it allow anyone to cut the podcast themselves and edit out sections they don't believe in? Yes, but who cares?

One rationalisation was that for entertainment such as TV, films and games, where we wouldn't necessarily be going in and editing a scene we don't believe in, proprietary licensing is fine. But for creations such as software that we'd want to be able to go in and fix a bug or add a new feature, we should be able to do that.

There's always the pragmatism - Jon's comment was that if it works when he needs it to, then he'll use it. As much as I love to host my own services and rely on my own infrastructure, I recently stopped running a personal Seafile server, as I couldn't be bothered with managing reliable backups and maintenance for our family. I'd much rather spend the extra few £s on a hosted service than spend hour(s) of my own time on it.

One comment was that actually, if we're spending the money anyway, why would we not put it in i.e. hosted Seafile services? This is a great point! I'm going to look to which of my services I can offload to others so I:

don't have to think or worry about it myself

can support upkeep of products

Not only that, but I'm going to look at actually setting up payments to projects I use daily, as it's really unfair me just taking without giving back. Unfortunately I don't seem to have a lot of time to spare, so it'd be good if I could compensate them with some money instead.

One final point on ethical ramifications of using certain software, media, etc is that actually it doesn't really matter - for instance, large companies such as Coca Cola have literally killed people but people still drink it. After that comment was brought up, I still saw people drinking it. It's hard to go out of your way to "do the right thing", but that doesn't mean we shouldn't try!

I have such huge respect for the hugely philosophy-driven people like Richard Stallman, and would love to be more rigid in how I approach the software and hardware world, but I feel it's one of those things that currently I need to be pragmatic, but with the aim to leave the world in a better place.

Andrew shared how Load Balancing can be used to improve scalability, high availability and for helping with server maintenance, as well as the networking methods that are applied in order to make it work.

Although I play with Amazon AWS' Elastic Load Balancers almost daily, it was really interesting to understand more about how they work and the different methods in which they can be applied within the network topology.

Although I'd first encountered Matrix at FOSDEM 2016, I'd not really kept on top of what's been happening in that space.

I could remember that it was all about having a decentralised open network for real-time communications, and that there was something about bridging networks i.e. IRC, Slack, Mastodon, but I didn't realise how Matrix could be used with arbitrary tech such as Philips Hue devices.

Ben explained the architecture of Matrix as a system with the various challenges of a distributed system with syncing state, giving us great insight into the complexities involved.

Ben also explained how they practice fully open development both in terms of Open Source and Open Communication with their issue tracker being used for all conversations, rather than there being some hidden communication channels used by the team. As with GitLab, I'm a huge fan of this method of Open Operations and the confidence and community involvement in these decisions.

Mike shared some photos of various error messages he's encountered at ATMs, billboards, and various other screens around the world. His main point was that instead of dumping out a massive error message to a user, we should instead strive to provide user-friendly, non-jargon messages that can help the user report the issue. In the ATM's case, we could say where the nearest other ATM could be. We need to consider the context for our users, not scaring them with weird error codes, and instead log them silently to provide the developers with a chance to debug them separately.

Unfortunately not as deep in the why you'd want to use Nextcloud over a proprietary solution like Google's cloud solutions, this talk showed the various steps and commands you'd use to set it up. Interesting to see the use of different apps such as DavDroid and ICSdroid as alternatives to the Google Calendar apps.

This was a late entry, given I'd not fully planned it. I mentioned on Twitter I wanted to talk about it:

So I'm doing one of the planned talks today at #oggcamp which has meant that I've not had a chance to fully prepare another talk I'd like to do around proving OpenAPI specs are representative of your API. It won't be a full 25 minutes and I'd hate to take a slot from someone else

I started by talking through Swagger/OpenAPI and the reasoning behind it; creating a standard, programming language-agnostic representation for REST(ful) APIs. I talked about how making the specs both human and computer readable was a great selling point, allowing tooling to exist around it, but also not requiring it for reading.

I discussed a use case for why you'd want to create them, with the example of some integration work we've been recently doing at Capital One on the PSD2/Open Banking workstream. Contracts for API services haven't always been the best defined, so having them fully fleshed out in a consumable format would be really awesome, and would prevent the integration issues we were seeing. This also helps to reduce the many places in which your API documentation can live - READMEs, Confluence pages, scribbled on whiteboards, etc.

I then spoke about how to get started with Swagger - autogenerating it from the codebase if possible, and then writing the rest manually. Although it can be a bit daunting, the manual touch is required to help assess if there are holes in your object model or duplicated resources, as well as helping to add a bit more context for your APIs. I talked about how the use of Models is key to understanding interactions with your API and to help reduce duplication.

Although generating nice UIs for your contract documentation through Swagger UI is great, but so is the ability to generate a client/server implementation from the spec.

This led me into a brief overview of Contract Driven Development, where we can use Swagger's client codegen ability to prove our API documentation matches our implementation. I won't go into this in any more depth, I have an article nearing readiness which will be more interesting. Originally I was going to do a talk on just this topic, but I'm glad I didn't as I didn't really have enough prepared to talk through it. Once I've got the article written, I'll be in a much better place to talkify it.

The twenty attendees all seemed to be interested, and I had some questions around the best way to hook it into existing applications, as well as some specific use cases.

One main bit of feedback I received was that because I didn't have any slides (as it was last minute) it meant I jumped straight into it instead of sharing who I was and why I was talking about it.

Throughout the weekend we could buy raffle tickets to try and win a variety of freebies, from leftover Chef swag to Pimoroni goodies to an Entroware laptop! All prizes were donations from various organisations, which meant that the profit from tickets and associated swag we'd bought (like a mug and T-shirt) would go to pay for the conference. Anna won a really cool Ubuntu Xenial Xerus USB with Ubuntu 18.04 on it:

Ending Remarks

One thing we found interesting was that there were actually very few attendees using Twitter, which I guess you'd expect from the group. It was still quite nice to see the principles living strong.

The second day was a lot better organised, with the order of the morning talks being decided by 1100 and the afternoon talks by 1300, making it easier to plan out where you'd be in for the sessions, rather than having to pop down to the boards each time in case there were any new talks added.

There still wasn't any organised timekeeping, so lots of talks were starting late and/or running past the allotted time, meaning we'd often miss the start of the next talk which was unfortunate, and I can imagine not helping the speaker by having a trickle of attendees through the first few minutes of their talk.

It's definitely refreshed in my mind that I need to get involved in Free and Open Source software, and the biggest thing I've taken back to Capital One is that we need to give back to the community!