TLDR

Today, open source communities struggle to scale because they are focused solely on building new features. Maintainers and core contributors need to invest in tools to make the software building process more dynamic and collaborative. With a code discussion tool, which introduces the ability to comment and discuss code natively in your IDE, open source leaders can create more trust in the community and empower more contributors to be involved in maintaining an open source project.

Introduction

Last year I wrote about my observations coming out of KubeCon, in short enterprises are ratcheting up purchases of open source software in new domains and the amount of projects is growing. Developers are building new ground breaking products focused on transparency at an amazing rate enabled by the rise of git and cloud services. Open source is increasingly touching new industries from data modeling to farming, where developers are pushing businesses to make their software publicly available. It’s safe to say we are at the peak of the adoption curve for open source products.

The adoption of open source technology represents a broader, seismic shift happening across the technology industry. Developers have been awarded more autonomy to choose which products they want to use and how they want to perform work. In some respects, developers behave similarly to any other consumer. Acquisition is difficult because the attention span of any consumer is low and options are endless. Developers are bombarded everyday with pitches for shiny new toys. If you struggle for a second to keep a developer engaged with your product, they will likely leave and join another community.

Investment into new product development is table stakes at this point. New open source tools can only scale if they are focused on growing (and keeping) developer mindshare from day one. I spoke to a number of open source communities at Kubecon and the feedback was consistent — they all prioritized continued product innovation, but very few thought deeply about investing into community engagement.
Tim Hockin emphasized this during his KubeCon keynote that open source technologies survive based on the strength and engagement of their respective communities.

Open source leaders engage with their members across several channels. The activism we’ve seen from community members to push technology companies in one direction typically happens online in forums (StackOverflow, Dev.To), messaging boards (Slack), or public comments in version control systems (GitHub, GitLab). Similarly to the retail industry, omni-channel interaction with community members is becoming more important. Maintainers are hosting Meetups followed by inquiries and discussions in a community Slack channel.

It’s easy for large projects with already high levels of penetration, such as Kubernetes, to engage their community with the resources of the Cloud Native Compute Foundation. Smaller, nascent projects have to fight an uphill battle with established projects for the same level of developer mindshare.

How can open source communities increase engagement

Open source communities have an enthusiastic base of contributors who are often working on projects outside of work hours — working out of passion rather than compensation. While the fragmented nature of open source allows creativity to flourish, the cost can be less engagement. Fortunately, there are a few tools, such as CodeStream that can help increase engagement while keeping the decentralized approach to building an organization.

Accommodate the distributed, global contributors

Consistent communication with contributors is difficult at a global scale under the status quo. Unlike most companies where workers are typically in close proximity to each other, open source communities by nature maintain a distributed, global user base. Developers can’t stand up and ask someone a question about the codebase. Communication on Slack becomes difficult when new contributors are added from different time zones. By the time a community member in one time zone wakes up to answer a question, a conversation has already moved higher in the news feed with multiple conversations happening about different topics.

An easy solution to the geographic barriers and impediments to a newsfeed would be attaching conversations and commenting right next to the codebase in your IDE. Anyone would be able to discuss code at any given time and not compete for attention with other more recent conversations. This method would allow anyone at any time to see the last comment or answer questions without having to scroll up in a feed to see prior comments. For contributors who aren’t in Pacific Standard Time or European Standard Time, this would be a huge plus to encourage more participation from under-represented geographies.

Keep conversations in a knowledge base to supplement a pull (or merge) request

A great way to keep contributors engaged is introducing the ability to see why a pull (or merge) request was executed, directly attached to code blocks in your IDE. Contributors would be able to understand the direct impact they’ve made on a project.

I had spoken with one project at Kubecon who mentioned it can often be months before a request is completed. This is due to the fact that a large user base will introduce more feature requests without any organization. This way when a request is finally completed, contributors won’t scratch their heads and endlessly search Slack archives for a conversation months ago to understand why the change was made.
Remove friction from the onboarding process to decrease new contributor dropout rate

The ability to view discussion on a block of code inside the editor would be helpful to onboard new developers. Many developers may lose interest in contributing to an open source project if they do not understand the documentation or the rationale for the project. With CodeStream, strategic discussions can be archived next to the code blocks inside your IDE. As a developer begins to make their first contributions to the project, the community can provide quick, informal feedback in the form of comments.

By expediting time for a potential contributor to understand the technical nuances in an open source project and provide feedback early on in the contributor’s journey, open source communities can decrease the drop off rate of contributors no longer interested in maintaining a project.

Increase collaborative peer reviews

“When an open source project becomes large it becomes increasingly difficult for a limited number of core contributors to review each and every code request submitted. Very quickly this becomes a bottleneck for the entire project and slows the progress…Implementing peer review is the most common practice for fixing this bottleneck…”
-David Hurley, founder of Mautic (open source marketing automation service)

CodeStream enables collaborative peer review in real time by allowing the core contributors and users to discuss code changes. CodeStream encourages a process when any user can voice their opinion. Collaborators are freed up with more time to do what they do best — build more features. They do not have to answer every question since any user is free to comment on the codebase. This mechanism also empowers any user to actively participate in discussions where they are comfortable having smaller, informal conversations.

Streamline customer support for enterprises

The benefit of open sourcing technology is providing more transparency. Potential customers can look “under the hood” to see how a new technology is built. Enterprises can properly audit the backend of software for any compliance or regulatory challenges. Open source effectively is a risk-free way for potential customers, who may want to buy a premium version of an open source product with enterprise controls in place to try the product first.

CodeStream is a great tool for core contributors to interact with these potential enterprise customers. Customers can point out specific code blocks which need to be edited or modified to use. This feedback layer works exceptionally well to ensure customers and contributors are looking at the same technology backend. Rather than go back in fourth on a Slack channel and look up specific instances, if a customer or general user who downloaded the product has a question, they can simply comment on the area to start a discussion with a contributor.