Open source software is at the heart of Codethink.
Codethink staff can often be found in attendance at open source conferences while Codethink, as a company, supports events in Europe and internationally each year. On a more day to day basis, Codethink engineers are regularly contributing to open source projects. Adam Jones is an engineer who was introduced to open source technology when he started at Codethink and ever since, his interest and passion for the FOSS world has grown.
I talked with him about his experience getting involved with open source and some advice he would give to people that are looking to get involved.
We also recorded a video of the interview
Tim: Can you introduce yourself?
Adam: Hi, my name is Adam Jones and I'm a software engineer at Codethink and I am a co-maintainer of freedesktop-sdk.
Tim: How long have you been contributing to open source?
Adam: I have been contributing to open source since I started at Codethink, which is just over a year ago. I still feel like I’ve only just scratched the surface, there’s still a lot to learn and, yeah. That’s quite exciting.
Tim: What was your first experience of open source software?
Adam: My first exposure to open source software was actually the GNOME desktop environment. When I started at Codethink they were hosting the annual GUADEC conference (which is the GNOME conference) in Manchester. I had the pleasure to attend that and learn all about the GNOME environment so that was quite interesting, that was my first experience.
Tim: How should someone get involved with an open source project?
Adam: Of course, this is the hardest question to answer because there's no single answer for any single person open source is quite a diverse space - It’s not just the Linux Kernel, as a lot of people will have you thinking, especially in the media. Open source now ranges from open web technologies to open standards… Yeah, there's a whole range of things to get involved in. The number one tip I usually give to people is you should be passionate, so if you find something you're passionate about that obviously makes it a lot easier to work on especially when you're working on it (a lot of the time) in your free time. If you enjoy something, you're going to work on it more.
The second bit of advice is that open source is not just about code. Like many big businesses there's all sorts of processes around some open source products because they're being used by, sometimes, millions of different people, so they need people that write good documentation, maintain the website, do releases, also who contribute to the code! So yeah, finding an entry point into a project in any of those areas can be very easy and beneficial to get involved. It's not just code.
Tim: Are there any misconceptions about contributing to an open source project?
Adam: I do feel like there is a lot of misconceptions around contributing to an open source project. One of the most common ones is that people feel a bit intimidated or scared to approach a new project and all I can say is that you shouldn't be. If you've ever done anything like a hackathon or joined a hobbyist club or even started a new job, you know, the same feelings and emotions that you get from doing that is the same when you come to a new community in open source but as long as you're respectful for their community guidelines, everyone will be very welcoming and will actively want you to be there and encourage you to contribute to the project.
The second misconception is that contributing to a project is all about code and again that just is not the case. As with any big software tool you've probably used you'll know there's docs, there's maybe a website, they have to do releases, of course, there is maintaining the code and that is very important but there's lots of other processes around creating a community that you can get involved in and that maybe just using the product, writing a user guide, maybe doing a youtube tutorial, contributing to the code, fixing documentation issues, there's all sorts of issues you can get involved in.
I think the third misconception is that when you do contribute it has to be of high standard and high quality and again, it's just not the case. People know that you're working, sometimes, and most of the time in your free time so they're very welcoming of that, you taking the time to go and contribute to a project and of course, people will be opinionated about the patch, or the fix, or the video but most of the time though, that's just feedback. They're trying to give you feedback and say "Hey, you could improve it this way or have you tried doing it that way?" and I feel that's quite a powerful way of learning. You will definitely learn from that.’
Tim: Are there any benefits to open source contribution?
Adam: Well, it’s kind of hard to not ramble on when I talk about open source and the benefits that it gives to people, but I always say that the number one thing is that it can really boost your confidence. It definitely did in my case. Once I got a patch into a project, I felt a sense of achievement, like I’ve actually contributed to something that people were using and appreciated. So I’d say the number one thing is that it gives you a boost in confidence.
Secondly, you’ll gain a lot of soft skills, so working with new communities, you might be working across different time zones which might not be a common thing in your day job, or whilst you’re at University. You’ll also learn how to follow processes. Code has to go through reviews or you might have to propose a new feature to a mailing list or raise an issue and document it in a specific case, so things like that. You’ll learn those types of skills. Most importantly, for me anyway, is that you’ll learn new technical skills. If you submit a code patch, especially, you’ll also get people who will review it who are sometimes way more experienced than you and to me, that is very valuable - getting feedback from people who’s code you admire. When they comment on your code, it’s quite nice. But not just code. As well, if you are contributing guides, documentation, artwork - you’ll also get people who are in to that and they’ll give you feedback and explain different ways to write guides, or contributing guides as well so you’ll pick up a lot of skills along those points.
Tim: How does freedesktop-sdk make itself more accessible for new contributors?
Adam: At freedesktop-sdk, we’ve worked very hard on this, (or at least we like to think we have!), putting a lot of processes in place. The first one is that the project is fully hosted on GitLab, which is the open source community edition, anyone can access and review our code there. We have the issue tracker there as well so everything is in the same place and people can go and review issues. With the issue tracker as well, we’ve also introduced the newcomers badge. If you’re a newcomer to the project you can search for that and filter issues that are accessible for newcomers, so I find that is quite a beneficial feature. We also have a contributing file and a read-me file. The contributing file gives you all the guidance you need to write a patch for freedesktop-sdk. If you can’t make a patch, we have some links to contact us. That leads to our irc, or mailing list so people are welcome to join there and ask questions and I think that’s quite good to lower the barrier of entry for new comers. Also one of the big features is that we have a public CI. If you submit a patch to freedesktop-sdk, we have the CI in place that will test and build your patch, you don;’t have to do that locally, so I think that definitely is great for newcomers who, maybe don’t have the most powerful hardware when working on the project.
Here are some ideas for communities to get involved in:
KDE GNOME Mozilla
- Automated Linux kernel testing
- Native compilation on Arm servers is so much faster now
- Higher quality of FOSS: How we are helping GNOME to improve their test pipeline
- RISC-V: A Small Hardware Project
- Why aligning with open source mainline is the way to go
- Build Meetup 2021: The BuildTeam Community Event
- A new approach to software safety
- Does the "Hypocrite Commits" incident prove that Linux is unsafe?
- ABI Stability in freedesktop-sdk
- Why your organisation needs to embrace working in the open-source ecosystem
- RISC-V User space access Oops
- Tracking Players at the Edge: An Overview
- What is Remote Asset API?
- Running a devroom: FOSDEM 2021 Safety and Open Source
- Meet the codethings: Understanding BuildGrid and BuildBox with Beth White
- Streamlining Terraform configuration with Jsonnet
- Bloodlight: Designing a Heart Rate Sensor with STM32, LEDs and Photodiode
- Making the tech industry more inclusive for women
- Bloodlight Case Design: Lessons Learned
- Safety is a system property, not a software property
- RISC-V: Codethink's first research about the open instruction set
- Meet the Codethings: Safety-critical systems and the benefits of STPA with Shaun Mooney
- Why Project Managers are essential in an effective software consultancy
- FOSDEM 2021: Devroom for Safety and Open Source
- Meet the Codethings: Ben Dooks talks about Linux kernel and RISC-V
- Here we go 2021: 4 open source events for software engineers and project leaders
- Xmas Greetings from Codethink
- Call for Papers: FOSDEM 2021 Dev Room Safety and Open Source Software
- Building the abseil-hello Bazel project for a different architecture using a dynamically generated toolchain
- Advent of Code: programming puzzle challenges
- Improving performance on Interrogizer with the stm32
- Introducing Interrogizer: providing affordable troubleshooting
- Improving software security through input validation
- More time on top: My latest work improving Topplot
- Cycling around the world
- Orchestrating applications by (ab)using Ansible's Network XML Parser
- My experience of the MIT STAMP workshop 2020
- Red Hat announces new Flatpak Runtime for RHEL
- How to keep your staff healthy in lockdown
- Bloodlight: A Medical PPG Testbed
- Bringing Lorry into the 2020s
- How to use Tracecompass to analyse kernel traces from LTTng
- Fixing Rust's test suite on RISC-V
- The challenges behind electric vehicle infrastructure
- Investigating kernel user-space access
- Consuming BuildStream projects in Bazel: the bazelize plugin
- Improving RISC-V Linux support in Rust
- Creating a Build toolkit using the Remote Execution API
- Trusting software in a pandemic
- The Case For Open Source Software In The Medical Industry
- My experiences moving to remote working
- Impact of COVID-19 on the Medical Devices Industry
- COVID-19 (Coronavirus) and Codethink
- Codethink develops Open Source drivers for Microsoft Azure Sphere MediaTek MT3620
- Codethink partners with Wirepas
- Testing Bazel's Remote Execution API
- Passing the age of retirement: our work with Fortran and its compilers
- Sharing technical knowledge at Codethink
- Using the REAPI for Distributed Builds
- An Introduction to Remote Execution and Distributed Builds
- Gluing hardware and software: Board Support Packages (BSPs)
- Engineering's jack of all trades: an intro to FPGAs
- Bust out your pendrives: Debian 10 is out!
- Why you should attend local open source meet-ups
- Acceptance, strife, and progress in the LGBTIQ+ and open source communities
- Codethink helps York Instruments to deliver world-beating medical brain-scanner
- Codethink open sources part of staff onboarding - 'How To Git Going In FOSS'
- How to put GitOps to work for your software delivery
- Open Source Safety Requirements Analysis for Autonomous Vehicles based on STPA
- Codethink engineers develop custom debug solution for customer project
- Codethink contributes to CIP Super Long Term Kernel maintenance
- Codethink creates custom USB 3 switch to support customer's CI/CD pipeline requirements
- Codethink unlocks data analysis potential for British Cycling
- MIT Doctor delivers Manchester masterclass on innovative safety methodology
- Balance for Better: Women in Technology Codethink Interviews
- Introducing BuildGrid
- Configuring Linux to stabilise latency
- Full archive