Barriers to Entry in Open Source

Note: I’m a firm believer in informing and educating others as a means to promote collaboration and exposure. Exposure being a core component in how awareness is spread for any given technology/process/design. The title can be a little misleading, but is meant to convey a problem which exists where people misunderstand the scope of Open Source and make assumptions about code contributions being the only source of value.

What Is Open Source?

The term open source refers to something people can modify and share because its design is publicly accessible. [1]

Open Source is evolving

What started as primarily software source code has since evolved to become synonymous with much more. Open Source now includes the sharing of information within and across many domains. Whether it is data models being versioned controlled and shared. Things like 3D printing and models being aggregated and shared on sites like thingiverse. initiatives for security like OSV and even safety critical spaces such as intelligence communities. 

All of that to say - Open Source is more than the code - it’s about people collaborating in meaningful ways towards the advancement of a domain. 

Culture of Open Source

The culture of a community is what will ultimately drive collaboration, contribution and adoption. The ability for any given community to consider and implement practices that enhance the pace for which any individual can learn, apply and contribute to said project will enable growth, and subsequently adoption. A project that refines user experience will be used more widely - thus a feedback loop where users understand how a system works can contribute to that refinement.

The culture consideration stems from multiple perspectives, such as:

• How does someone learn to use the tool/platform/data?
• How can someone seek further clarification for questions and/or inconsistencies? (And what do maintainers do with this information)
• How does a community expose areas where a newcomer can learn and provide value? 
• How does a project interact with the community to foster new ideas and collaboration?

What does it mean to contribute

This is a key area that I wanted to articulate, and hopefully drive some conversation around. Contribution is no longer only modifications to source code. For platforms such as GitHub, this may be the primary mechanism for getting included in the list of contributors - but I consider updates to code an equal slice to these other portions of the pie:

• Async/sync discussions in open forums (such as Slack for async and Meetups for sync)
• Reporting bugs, inconsistencies, and/or unexpected workflows as Issues
• Community engagement and knowledge of the domain
• Additions such as testing that validate runtime behavior

To also include documentation, I separate this as it may be included in the code, as ideally documentation should live as close to the code as possible.

How you as an individual can get started

Find an area that you are passionate about and/or are interested in improving - this can be a technology, a platform or a community of practice (and other projects). Conduct learning into how that space operates and methods to collaborate with others. Learn, learn, learn and then help others learn. In my other article Turning an Experiment into a Habit, I discussed how simply monitoring a space allowed me to educate others and also be educated by others through that same methodology. 

How your organization can provide meaningful value to Open Source

Identification of technologies that are present within your products and/or around your internal infrastructure. Use that list and query Subject Matter Experts to determine if there are any areas of improvement within the use of those tools/platforms that can be feed back to the source. 

Have you and/or your team ever implemented a “work-around” to solve a problem due to inconsistent runtime behaviors/assumptions? These are great reflection points to understand - were we really using the tool incorrectly? - or should the tool/project likely perform those operations as expected? The latter being a great starting point for initiating discussion that may lead to maintainers understanding users better and tools advancing.

If you are an advocate for Open Source or interested in doing so within your company/organization, I will be writing a future article around how to get started and build engagement for Open Source through communities of practice - to include the value that Open Source engagement provides back to your organization (think return on investment from a cultural perspective).

Important Considerations

I do want to call out that there are considerations to be made when collaborating with others in Open Source domains. Most important is that all discussions/issues/contributions are important - but ultimately a maintainer has the right to accept or deny any modifications presented. This is why culture is so important for Open Source domains.

To clarify - maintainers are ultimately responsible for the current and future direction of the project. Being a domain expert means understanding how changes will impact the current backlog, priorities and architecture. While a contribution may be with the best intent - likely there are considerations that may present themselves in a manner which that contributions value will not be realized or may conflict. 

That is not to say that the denied contribution was not valuable. The opposite - all contributions submitted are traceable artifacts to decisions made and education for all parties involved, current and future. The value of a denied contribution can sometimes be as equally valuable as an accepted contribution. 

Discuss

I would love you hear your thoughts! What do you agree or disagree with? What other barriers do you or your company face when it comes to contributing to domains that you interact with? We have a number of people/companies who are still figuring this out - so let's open the discussion!