Advantages of Participating in Open Source Projects

There are clear advantages for individuals who take the time to participate in the world of open source.

open-source-software

Open Source Software (OSS) is all around us, and it is traditionally seen as the preserve of developers. OSS brings benefits to a much wider demographic than solely developers, and participation in OSS projects by non-technical contributors is, in general, both welcomed and beneficial for the long-term success of an open source project. As we explore alternative ways of contributing to OSS and the advantages it can bring, we’ll assess the benefits for the core product, the contributors, the community, and end-users alike.

OSS benefits for consuming organizations are a well-discussed topic and it’s becoming more widely accepted that leveraging OSS affords the ability for companies to deliver their own software faster with higher quality and better security. Additionally, it opens the potential to innovate faster and utilizes the expertise of the wider technical community directly within the walls of an organization.

There are clear advantages for individuals who take the time to participate in the world of open source. It can be invigorating to participate in new communities, and in general, most OSS communities encourage new participation. The goodwill and inclusivity that exists at the community level offer more scope for creativity and higher levels of satisfaction for many contributors. Of course, there are career benefits too, with many working full-time within the OSS landscape and others leveraging contributions as a key differentiator on their resume.

It is not all plain sailing. There are many challenges to delivering successful open source projects. Many struggle to have long-term viability and this can often be traced to elevated levels of discord between the contributors, lack of cohesive documentation to facilitate project adoption or fresh contributions, poor or even no support channels, and even lack of transparency around roadmaps, goals, and the vision for the project.

These challenges are addressable, but not by developers alone. Companies delivering closed source software use staff from multiple disciplines in order to deliver a polished quality product. It may not seem like there is a natural fit in the open source scene, however, I believe multi-disciplines are in short supply in OSS, and there are a number of areas where people can contribute and deliver benefits to open source.

Let me take you through a few:

User Support – Being there to help users solve problems is something you may have already encountered with Stack Overflow, Slack/Discord/Gitter groups, and GitHub discussions. Get involved in more general groups like https://apisyouwonthate.com/ or https://www.ministryoftesting.com/ where you can talk about or just listen in to some of the organic conversations that happen around code, as it is all built by people, for people.

Documentation – The primary way to communicate with users, you can help out with small changes like a typo, help rewrite larger pieces, or add new content. Think of it as an open source wiki, and you are all the curators.

Translation and localization – Just knowing a different language, even if you know nothing about the tool, can be incredibly valuable. Creating translations and localization can rapidly increase the inclusivity and diversity of your project.

User experience design – Often, the users of open source software are opaque to the creators of the projects, and the only avenue for conversation is usually via GitHub issues. We have seen human-centric and UX design principles play a pivotal role in improving user experiences in commercial projects, and helping feed that mindset into OSS projects can massively increase and broaden their appeal and make the experience better for everyone.

Testing & QA – Tests provide some of the best living documentation. OSS code without good tests is a red flag, but you might find the code/project incredibly useful. Adding tests or even reviewing the existing ones and making sure they are fit for purpose is also valuable. You can get involved in beta testing or early release programs where you can try out new features before others and provide feedback, forming the project’s development and helping build the tool you want.

Development – This is DevPro Journal, so you all know how to code, but what about the architectural diagrams, the vision, the engineering principles? You can help instill order in the chaos by providing those who do want to code a path of least resistance. Developer experience is not just for the users of the tools but the makers as well.

Infrastructure – Open source projects are often more than code. The code may need to be hosted somewhere or have specific release pipelines to build systems. Thinking about how we monitor these systems’ usage and leverage multiple open source tools to help provide a unified view aids the maintainers of a project in helping it become more effective.

Advocacy – Maybe you think an open source tool is the best thing since sliced bread and you can’t stop yakking on about it. Tell someone, your friends, your colleagues, write a blog post, or do a 99-second talk at a conference. Get in touch with the authors of your tool and see how you can help them. You might have had success in implementing the tool/product and want to provide coaching and support. Some OSS programs have advocacy schemes where you can get some cool swag and help in all kinds of different areas.

Marketing – Let’s face it, developers aren’t always the greatest marketers. We might have made the coolest tool known to man, but we silently stick it in a GitHub Gist. If it’s great, let’s shout about it, but sometimes you just want to have your head down in the code. Open the doors to people with marketing backgrounds, help them build empathy with your developers, and understand their wants and needs. Maybe do a little pair programming with them. 😊 Bringing users to your OSS will lead to improvements in your code, given Linus’ law is correct, “given enough eyeballs, all bugs are shallow.”

If you are an engineer who writes open source software, some of this list may seem like extra work, which removes you from the dopamine hit of writing code. A good support network of multi-disciplined contributors and well-formed goals will aid in bringing in extra help and improve each of these areas, allowing individuals to concentrate on the part of open source that really matters to them, giving the platform the best chance of success.

As we see the proliferation of OSS bleed into our daily lives, I implore you to find the OS tools that you love, and appreciate the amazing people you have met in your career from all walks of life while improving the landscape. After all, we are all standing on the shoulders of giants.


SHARE

Yousaf Nabi is Developer Relations and API Evangelist at SmartBear. He has more than 11 years of experience as a software test engineer, starting his career in accessibility testing at a large UK banking organisation. He has worked with financial, healthcare, betting, and telecommunication providers testing software and helps developers to migrate from traditional software development methodologies to a leaner Agile based approach.