Non-code contributions

While most people think of contributing code when they think of open source participation, and most project contribution guides focus on code contributions, there are many other ways to contribute to an open source project.

Ways to contribute

There are many broad categories of non-code contributions. This list is not comprehensive. Indeed, whatever your passion or expertise, there is probably a place for you to participate in some Apache project, or at the Foundation level.

Documentation

All software needs some level of documentation. And documentation needs writers, as well as readers. If you are a writer, particularly one with an eye for information organization, your contributions will be welcome in almost any project community.

There are often easy starter contributions, such as grammatical or spelling improvements.

Great value to the project can come from collaborating directly with the software developers to explain features more deeply and create examples and demos. You can work with users to help them describe their use cases.

Working with testers to describe their failure scenarios and desired new functionality is a way to accelerate innovation, and help developers understand vague tickets.

Translation and localization

Most documentation of Apache projects is written in English. Providing translation and localization of these documents is a great service to a project, and helps adoption across a broader part of the world.

Translation and localization of the user interface helps users have a better experience with the product, and that, in turn, speeds adoption and user feed back, and, thus, further innovation.

Start by having a conversation with the project about whether they have a translation/localization process in place. Tell them what language(s) you speak, and, if possible, give some examples of your work.

Projects should consult with Infrastructure about what translation/localization tools are available and recommended.

Design

Programmers usually design their project website, and the user interface of their projects. There are opportunities for anyone with an artistic eye to improve the user experience, both of the product itself, as well as the website, logos, and other imagery around the project ecosystem.

Designing banners for conferences, mascots, promotional materials, and blog posts can make a project more engaging and welcoming. If the project does not have a logo, work with the community to suggest possible designs.

Helping improve the user interface of a product can result in more users adopting it. Work with testers and users to understand which parts of the product are harder to use or understand.

Read through the website, and suggest places where images might make the flow more attractive. Be sure that you use only images that you have an appropriate license to use. For example, you can use images from photos.apachecon.com under a Creative Commons license.

Event support

Many ASF projects host their own events, either specific to one project, or across several related projects. These events often rely on external vendors or conference planners, but there is almost always an opportunity for volunteer support in planning, promoting, and executing these events. This may involve site planning, design and promotion, speaker relations, sponsor acquisition and relations, or University outreach, among many other details.

If you have experience running events of any scale, your expertise will be greatly appreciated by these projects.

You can see a list of approved upcoming events on the Apache events website, or by searching for meetup or conference on lists.apache.org.

Community engagement

One of our mottos at Apache is “Community Over Code.” A strong community produces better software. Strong community is built on trust, respect, and communication. These things don’t just happen - they take hard work.

An important contribution that almost anyone can make is investing in that community. A community engagement contribution might look like one of the following:

Friendly communities grow faster, and retain people longer.

Vendor engagement

Many Apache communities rely on participation from the various vendors that rely on our projects. While we recognize individual contributors rather than their employers, it can be very valuable to do proactive outreach to vendors to encourage them to participate in community-friendly ways.

You can help by identifying companies that have products or services that depend on a particular project, and reach out to them to understand their needs, their frustrations, and their goals. Encourage them to participate in the open to achieve those goals, and to talk about what they are working on.

Projects should not be expected to care about a company’s timelines, customers, or product milestones. But understanding what those are may result in helpful collaboration, either between individual contributors, or between interested companies.

Have friendly conversations with the marketing departments from interested companies about appropriate use of trademarks. This avoids unpleasant situations later on, and thus helps avoid a company having a negative interaction with our Trademarks team.

Identify a contact inside each participating vendor who is friendly to Apache community norms, and offer to help them make the case for upstream engagement – sometimes an outsider voice can be more persuasive.

Encourage your contacts to submit talks to the project’s summit, meetups, or other conferences, about their work in the project. That, in turn, will help individual contributors to raise their profile within their employer, and demonstrate the value of earning trust in open source communities.

Marketing and promotion

Getting the word out about a project is critical to building your project’s community. There are many ways to do this, and this is a fantastic way to contribute to a project.

Does the project have a social media presence? Offer to help schedule and produce content for those channels. Use those channels to promote releases, features, and volunteer opportunities, as well as to celebrate individual contributor milestones.

Conduct interviews with users who have interesting use cases, or vendors who offer interesting services based on the project. Publish these interviews (with pictures!) on your project website or blog.

Work with Marketing & Publicity to find ways to promote your project. Volunteer to do an interview with PlusOne and coordinate with the dev list to find the right people to be the voice of your project.

Testing

Your project probably has automated testing of some kind, but nothing beats a human tester. Test, and vote on, each release candidate, even if your vote isn’t binding (i.e., if you’re not a PMC member).

Download and try out the product, naively following the documentation to ensure that it accurately represents how to get it working. Report your findings in detail - what you tried, what happened, and how it differed from what you expected to happen.

Try out documented features, and see if they work how you expect them to. Report your findings.

Offer to interview new users to find out their experience - the beginner’s first experience with your project’s product can be very eyeopening to people who have been using it for years and know how to get around limitations.

Project management

Apache projects are not usually tied to release schedules, feature sprints, and other strict planning that you see in commercial software development efforts. However, there’s often value in having someone who tracks what is being worked on, what’s next on the roadmap, and what is intended to be in upcoming releases. Having project management skills can be a real benefit to a project that has a diverse set of developers all working on different things. A project manager can coordinate communication to ensure that everyone is aware of priorities, and help avoid conflicts.

If you’re good at this kind of thing, come talk with us and we’ll try to help you find a good match with a community seeking those skills. If you’re a project that needs this kind of help, let us know!

Others

This is not an exhaustive list. There are other places that you can get involved in a project, or in the Foundation. If you have expertise in law or trademarks, accounting, or public policy, your expertise is welcome and sought after. Come talk to us about your skills, and how you would like to participate, and we’ll try to make introductions.

A word about AI

It can be tempting to use AI to analyze some portion of a project, whether that’s code or documentation, and then submit patches based on what the AI says. We request that you carefully read the ASF Generative Tooling Guidance before doing so. We also request that you remember that whatever the source of your contribution, you are personally responsible for the quality of that submission.

Many open source projects receive a huge number of AI-generated contributions, and find that many of them are poor quality, or just wrong. While it may be fine to use gen-ai as a starting place, do not simply submit patches without first reviewing them yourself for correctness and quality, as this will likely result in future contributions being rejected, or even in your being blocked from further participation.

Recruiting and encouraging non-code participants

Because most people think of code first, it’s important for projects to actively recruit and recognize non-code participants. There are a number of ways that you can do this.

Identify specific non-code contributions that are needed or wanted. Open tickets as you would for any code issue. This signals that non-code contributions have the same importance as code contributions.

Consider creating specific named roles (e.g., Project Manager, UX Design Lead, Vendor Outreach Coordinator) for non-code roles. This makes it easier to attract the skills that you are looking for, and shows that you value those roles.

Recognize and celebrate non-code contributors in the same ways that you would coders. You can, and should, extend Committer status to non-code contributors. Mention in release notes everyone who contributed to a particular release, including these non-code roles.

In conclusion …

Like any project, open source projects are composed of many different participants with different skills. Foster a community where these different skills are treated as equal participants in the larger whole. Celebrate non-code contributions, and grant full project membership (Committer and PMC status) to non-code participants.