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:
Other Content
- Speed Up Embedded Software Testing with QEMU
- Open Source Summit Europe (OSSEU) 2024
- Watch: Real-time Scheduling Fault Simulation
- Improving systemd’s integration testing infrastructure (part 2)
- Meet the Team: Laurence Urhegyi
- A new way to develop on Linux - Part II
- Shaping the future of GNOME: GUADEC 2024
- Developing a cryptographically secure bootloader for RISC-V in Rust
- Meet the Team: Philip Martin
- Improving systemd’s integration testing infrastructure (part 1)
- A new way to develop on Linux
- RISC-V Summit Europe 2024
- Safety Frontier: A Retrospective on ELISA
- Codethink sponsors Outreachy
- The Linux kernel is a CNA - so what?
- GNOME OS + systemd-sysupdate
- Codethink has achieved ISO 9001:2015 accreditation
- Outreachy internship: Improving end-to-end testing for GNOME
- Lessons learnt from building a distributed system in Rust
- FOSDEM 2024
- QAnvas and QAD: Streamlining UI Testing for Embedded Systems
- Outreachy: Supporting the open source community through mentorship programmes
- Using Git LFS and fast-import together
- Testing in a Box: Streamlining Embedded Systems Testing
- SDV Europe: What Codethink has planned
- How do Hardware Security Modules impact the automotive sector? The final blog in a three part discussion
- How do Hardware Security Modules impact the automotive sector? Part two of a three part discussion
- How do Hardware Security Modules impact the automotive sector? Part one of a three part discussion
- Automated Kernel Testing on RISC-V Hardware
- Automated end-to-end testing for Android Automotive on Hardware
- GUADEC 2023
- Embedded Open Source Summit 2023
- RISC-V: Exploring a Bug in Stack Unwinding
- Adding RISC-V Vector Cryptography Extension support to QEMU
- Introducing Our New Open-Source Tool: Quality Assurance Daemon
- Achieving Long-Term Maintainability with Open Source
- FOSDEM 2023
- Think before you Pip
- BuildStream 2.0 is here, just in time for the holidays!
- A Valuable & Comprehensive Firmware Code Review by Codethink
- GNOME OS & Atomic Upgrades on the PinePhone
- Flathub-Codethink Collaboration
- Codethink proudly sponsors GUADEC 2022
- Tracking Down an Obscure Reproducibility Bug in glibc
- Web app test automation with `cdt`
- FOSDEM Testing and Automation talk
- Protecting your project from dependency access problems
- Porting GNOME OS to Microchip's PolarFire Icicle Kit
- YAML Schemas: Validating Data without Writing Code
- Full archive