How Organizations Can Get the Most Out of Their OpenSearch Contributions

This post is based on the talk I gave at OpenSearchCon 2022 in Seattle. It’s drawn from my own experience and from industry research done by others. Your experience may differ, but I suspect the conclusions are the same. The focus here is on what you, as a contributor, can actually do.

My motivation is simple: I want to help new users make quality contributions, help organizations benefit from the contributions they make, and help OpenSearch succeed. Better contributions are good for everyone.

Why contribute?

There are many reasons to contribute to an open source project. A few stand out:

• Spark innovation. New capabilities have to come from users. A single contribution can stimulate the community and lead to more contributions that ultimately benefit you.
• Build an organizational reputation. Contributing makes it easier to attract talent, become known to customers, generate marketing around new features, and establish your organization as an expert in the field.
• Build a personal reputation. Research on code review in open source found that developers with a strong reputation get quicker first feedback, complete review in less time, and are more likely to have their changes accepted.
• Avoid maintaining a private fork. Nobody wants to maintain a private fork. Nobody.

The biggest barrier is support

If contributing is so valuable, why isn’t open source used even more? The research is remarkably consistent on this point. Concerns about the level of support are the main barrier to open source adoption (Red Hat, 2021 and 2022). The same concern, a lack of formal support, was named at the Open Source Business Conference back in 2004. That’s a 17-year gap with the same answer at the top of the list.

The lesson for contributors follows directly: don’t commit and forget. Success requires the whole community, and your contribution doesn’t end with a pull request. Join the community, support the users of your work, provide updates, and give the community what it needs to support what you built.

Three types of contributions

Thinking about contributions that add or modify functionality (not bug fixes, documentation updates, or non-code work), it helps to sort them into three types:

• Type 1: useful only to you and your organization. Usually something to make your own life easier for a very specific use case. Often small changes, and sometimes not strictly necessary.
• Type 2: useful to you and a few other organizations. More general, and typically larger and more complex. Applicable to other users with the same use case.
• Type 3: useful to many of the project’s users. The meat and potatoes of open source. These often add an entire new set of features, tend to be the largest and most complex, and have wide applicability. They’re welcomed by the project but take real effort to merge, so see them through to the end.

Getting each type accepted

Type 1 and Type 2 changes can be a hard sell. They serve specific use cases, offer less motivation for maintainers (and more burden), and are unlikely to attract new users or contributors. To make your case:

• See whether the change can be made more generic.
• Provide thorough documentation with the change.
• Engage with the community early to discuss it.

Type 3 changes are the opposite. They’re most likely to be welcomed, and they carry the most potential for your organization, but they’ll require effort to discuss the code and documentation before merging.

Making a contribution

Before writing any code, have a discussion with the team first. Talk through the objective on the forums and in the issues. Then, as you work:

• Write thorough documentation.
• Write comprehensive unit tests.
• Be responsive to comments and requested changes.
• See it through until the end.

After the contribution is the most important part

Writing the code is only the coding part. Everything that makes a contribution a success happens afterward:

• Publicize it. Write a blog post, record a video, give a conference talk.
• Don’t abandon the project. Support your changes for users and keep them current as the code evolves.
• Expand the documentation. Add more examples and sample code.

A good example is the work to integrate Learning to Rank into Apache Solr (SOLR-8542). It didn’t stop at the code. It came with documentation, a “Quick Start” set of usage examples, a blog post, and a conference presentation. That follow-through is what turns a merged pull request into something people actually adopt.

Summary

Open source adoption is slowed by fears about a lack of support, and supporting your own contributions is one of the best ways to counter that and promote adoption. Contributions are also a great way to build an organizational reputation. Plan your contributions, see them through, and use them to make your organization an expert in the field.

If you’re working on OpenSearch and want to talk through any of this, use the Contact Jeff button up top.