Article originally posted on InfoQ. Visit InfoQ

Open source usage and contribution have significantly increased in recent years and continue to be a formative source for developers across both their personal and professional projects. Contributing to open source projects has become a rite of passage of sorts for many new entrants to the field, and open source communities often provide great learning and networking opportunities while helping early developers build a portfolio of their technical work. 

In many ways, contributing to open source projects has also become easier than ever. Advancements in software collaboration and development platforms such as GitHub have democratized the opportunity to contribute to open source, and industry events such as Hacktoberfest or community forums have become great places for developers to find their first project to contribute. 

There’s little to no debate over the fact that open source software is critical to the tech industry and the developers within it. And yet, the open source community still finds itself hindered by a variety of challenges. The communities built and the benefits offered by open source are incredibly impactful — and engineering leaders would do well to encourage more participation within it, both for their teams and across the industry at large. 

The Face of Participation 

According to a recent study by DigitalOcean on the state of the open source community, approximately 50% of developers surveyed said they participated in open source over the past year. Of those who participated, nearly all (93%) said their level of participation either grew or remained the same since the start of the pandemic, showing that despite the wide-ranging work-life disruptions of the past few years, developers who are committed to open source have found ways to integrate the practice into their new routines and their own “new normal.” 

The Challenges of Contributing to Open Source

However, even the most committed developers will admit that time constraints are one of the biggest barriers to continued work on open source projects. DigitalOcean’s study found that most developers who do participate in open source spend about 1-5 hours a week on contributions and cite “lack of resources/time” as well as “technical debt” as two of the top challenges they face today. 

In addition to these time constraints, the open source world can sometimes be unwelcoming to those that strive to participate. Communication between contributors on open source projects can devolve into “contextual, entitled, subtle and passive-aggressive” comments according to one study on open source dynamics by Carnegie Mellon, or contributors may find themselves faced with contribution policies that are rigid and difficult-to-navigate. Communication between contributors on open source projects also breaks down quickly when projects face deep documentation debts. When there are time and resource constraints on open source projects (which is the majority of open source projects), proper documentation is the first thing to suffer. However, without thorough documentation, newcomers are faced with a very steep learning curve that makes it difficult to contribute unless they’re already very familiar with the project. 

Projects often also suffer from the same diversity and inclusion shortcomings as the rest of the tech industry. DigitalOcean’s own research has found that while most developers do feel that inclusivity in open source has improved over the past few years, there’s a disparity in this sentiment among members of minority groups – 26% of those who identify as part of a minority group disagreed that open source is inclusive, compared to just 12% of non-minority groups. Contributors that help manage open source projects have turned to a variety of solutions to try to mitigate toxic behavior, such as enforcing codes of conduct through bans and aggressive moderation, but even these solutions rely heavily on the time commitment of moderators to these projects.

In its current state, contributing to open source seems to straddle a line between “hobby” on one end and “volunteer work” on the other. Developers that carve out time for open source projects are doing important and innovative work, but this work often goes by unacknowledged by the parties, particularly companies that benefit from it. How open source software happens (i.e., how software is built, developed, and revised by mostly un/under-resourced strangers online) is increasingly incongruous with the role that open source technologies play in companies’ development today. 

What Open Source Brings to the Table 

Time after time, engineering leaders and developers have admitted to the outsized impact that open source software has within their companies. 64% of developers have stated that their company uses open source code for 50% or more of their software, which is even higher among startups and small businesses. 35% of startups and SMBs have used open source code in 50% or more of their software, compared to 28% of enterprises.

When larger companies do speak out about open source, it’s often from a security standpoint. Companies such as Amazon, Google, and Microsoft have joined foundations and organizations such as the Open Source Security Foundation (OpenSSF), which seeks to improve cybersecurity practices within the development and implementation of open source and to secure the “supply chain” of open source. These groups and organizations are important to the long-term success and sustainability of open source software, but are also less focused on addressing the day-to-day barriers that developers face in keeping open source projects maintained and growing. When developers are asked about security considerations, most (43%) believe that employing dedicated security experts to help oversee projects would improve their security, or believe that increased compensation and training for contributors themselves would help improve security. 

On a smaller scale, developers of all levels turn to open source repositories to solve a problem, expand their skills, or tackle new scenarios — all with resulting personal and professional benefits. 35% of developers who contribute to open source said they’ve gained enhanced skills from their contributions, 19% said they’ve encountered networking opportunities, and 11% even found job opportunities. A strong open source community is also key to keeping developers coming back to contribute: 32% of developers said open source contributions help them feel “purposeful or part of a wide community,” and 20% have even stepped into mentorship roles, helping other community members develop their skills. 

Despite being largely unpaid, volunteer work, mentorship and community play a key role in why open source still sees such high activity and engagement from developers even as they cite massive time and technical debt challenges in their professional roles. GitHub’s 2021 State of the Octoverse shows that a commitment to mentorship in open source communities results in a 46% improvement in productivity on these projects. This effect is also seen in the workplace, where “mentorship almost doubles the likelihood of a strong culture.” Under the right environment, open source is better due to strong developer communities, and developers are better because of strong open source communities. 

The Road Forward

When the question of how companies and organizations can give back to open source communities arises, payment is often one of the first topics to emerge. Payment for open source contributions is a highly debated topic. On the one hand, a majority of developers (53% in DigitalOcean’s study) seem to agree or strongly agree that individuals should be paid for their open source contributions, while on the other, there are developers that fear creating monetization or funding structures for open source may result in a more closed ecosystem of development, instead of a more open one. 

If companies balk at the insinuation of paying for open source software, or paying for contributions, there are other alternatives that some industry leaders have been exploring as a way to engage deeper with communities and “give back.” For example, last year Cisco hired its first Head of Open Source to act “as connective tissue” between open source initiatives, Cisco customers, and different business groups with the hopes of supporting those developers and maintainers that do “what can often be invisible work.” However, the creation of these types of roles or initiatives depends largely on having someone to advocate for the open source community internally, and to illustrate the ROI on building up open source communities. More recently, these types of efforts are falling to developer relations (DevRel) and developer advocacy teams, the likes of which are growing and expanding at some of the largest tech companies. 

Developers also see companies potentially allocating time to open source contributions during work hours as a potential solution to challenges of both time and deprioritization. 79% of developers surveyed agreed or strongly agreed that companies should give time during work hours to contribute to open source. In the future, open source contributions could be included in developer job descriptions, or companies could begin wrapping open source time into the type of employee volunteer and social good programs typically seen in larger enterprises. Particularly in the post-pandemic workplace, employees now more than ever are more likely to want to contribute their time and skills to efforts they see as worthwhile or giving back to society. By not encouraging open source contributions through dedicated work time or through volunteer programs, companies may be missing out on a very neat solution to issues of open source reliance and larger employee engagement. 

The question of incentivizing participation is perhaps also a generational one as well — less experienced developers (with a year or less of experience) are more likely to have participated in open source in the past year than more experienced developers. We can speculate that perhaps more experienced developers are running into larger problems of time constraints and bandwidth as they grow into more demanding roles, and it’ll be up to companies to figure out how to level the playing field so that all types of developers are given the opportunity to get involved in open source initiatives that are run at the company-level. This may look like baking in time in production schedules for open source contributions and reviews, or making open source responsibilities a critical part of certain roles or titles. 

Ultimately, engineering leaders, companies, and individual developers will have to work in tandem to effectively scale the innovation and benefits that open source offers to the industry without losing the overall values of community and collaboration that are so key to open source projects. As it stands, open source projects represent some of our best, most collaborative, and most impassioned uses of technology, where developers find mentorship and new opportunities to develop their skills in ways most aligned to their interests. As most engineering professionals and team leads can recognize, workplace communities could use a little more of this spirit.