8 non-code ways to contribute to open source

Image by:

Opensource.com

Whether you're a novice programmer, a seasoned veteran, or not an engineer at all, there are many ways to contribute to open source projects beyond coding.

Compared to proprietary software, open source projects tend to be relatively short-handed when it comes to non-engineering contributions, so don't shy away from open source just because you're not a coder. Your blog post or design skills could be much more meaningful to the right project than just another line of code.

So, here are a few bite-sized ways to contribute to open source that you can do right now.

Advocate

The easiest way to start contributing is to be a great user of open source technology.

This means using open source apps and choosing open source software when you have a choice (or at the very least, giving it a try). For instance, when the organization you work for is considering whether to use a proprietary app to solve a problem, consider researching and advocating an open source alternative.

Unlike SaaS (software as a service), open source software is available for installation on your own server (or your company's data center). Privacy, security, and customizability are often key advantages of open source solutions.

Googling "open source alternative to X" is a great way to find awesome projects like Rocket.Chat (team chat), Wekan (Trello-like kanban tool), Etherpad and Hackpad (collaborative text editing), EtherCalc (collaborative spreadsheets), HackerSlides (collaborative slideshows), Piwik (Google Analytics alternative), Ghost (blogging app), and many more.

A great place to find lists of these apps include list sites, one-click install lists, and popular blog posts, such as:

Speaking of blog posts, you could write one of those blog posts yourself... to advocate for open source software, of course!

Educate

Proprietary software companies often have dedicated marketing teams to get more users, but your favorite open source project has something better: you!

Educate others on why your favorite open source projects are important. This can be anything from writing a life-hacks-style blog post on how you use a particular open source app to get things done, to giving a lightning talk at your local hackerspace on your favorite project. You could even write a review of the pros and cons of similar open source apps, as seen in John Light's 5 open source alternatives to Slack.

When you write a blog post or give a talk about your favorite open source apps, you'll be speaking candidly from personal experience. If I were listening to you, I'd definitely trust your independent blog post review over an ad produced by a slick, smooth-talking marketing professional.

A few of my favorite examples:

Jack Singleton's talk, author of HackerSlides and lead dev on SandForms, about Sandstorm at Chaos Communication Camp. He also organized a Sandstorm booth at the Digital Rights in Libraries Conference.
Oli Evans's talk about writing apps with Meteor at LXJS.
Audrey Tang's talk, author of EtherCalc (and much more), on open source enlightenment (co-written with Allison Randal) illuminating the philosophical and social principles of the free software movement. She also translated the Sandstorm speaker kit into Chinese.

Translate

Sometimes it can be challenging to contribute to open source when your primary language isn't English, but this can also be a very valuable asset. Translation (or internationalization / localization) is an extremely valuable contribution that can open up software to a much larger user base.

For instance, Wekan users translated strings in Wekan to 17 other languages. And Audrey Tang translated the Intro-to-Sandstorm slides into Chinese.

Sacha Greif, co-author of Discover Meteor (my favorite Meteor textbook), started an open source translation project of his book (originally published in English). This is a translation project on a massive scale, with over 200 contributors translating to 32 different languages.

Of course, not every project is set up to easily accept translation contributions, so the best thing to do is to find and ask the authors or maintainers. Try to find a mailing list or Google Group. If they don't have one, it's OK to ask the authors directly.

Not all open source software users are monolingual English speakers. I live in the US and notice it can be too easy to take the experience of monolingual English speakers for granted and accept it as a default, but the human experience is so much broader and more diverse than that. Helping an open source project with translation is an incredibly helpful way to contribute because you're making it possible for many more people in the world to make use of your favorite open source project. If you're fluent in more than one language, translation is a great way to contribute.

Design graphics

If you've got design skills, you can help a lot of projects who need help. Sometimes backend-minded developers need some assistance making their icons and other graphics visually appealing and accurately communicating the purpose of the app.

Open Source Design (OSD) has this job board to coordinate designers and open source projects (started by Jan Borchardt). Want to help? Share this board with a designer near you. (And thank you Simon Vansintjan for bringing OSD to the attention of the Sandstorm community.)

^{Rust's "Rustacean" and OpenHatch's "Sufjan the OpenHatch penguin."}

I also wanted to give a shout-out to some of the open source design work that I've had the good fortune to appreciate up close. I really love this amazing Rustacean T-shirt that Karen Rustad Tölva (Lead UX Engineer at AeroFS) made for Rust, and the penguin mascot she made for OpenHatch. Also, check out the logo for Cap'n Proto (serialization protocol), which was contributed by Amy Wibowo (ex-Airbnb engineer, author of Bubble Sort: CS zines). And I'm really fond of the beautiful icons that Nena Nguyen at Sandstorm has been making for open source web app authors.

Improve UX & Report bugs

Proprietary software companies often have dedicated professionals working on UI/UX (user interface and design) and QA (quality assurance), but your favorite open source project could probably use your help in these areas. Even if you consider yourself a novice user, it really helps to be proactive in reporting issues from bugs and edge cases to UI/UX issues, like buttons that seem to be inconveniently located or confusingly named. Experts who have spent a lot of time looking at something can never truly look at it with fresh eyes because they can't unlearn what they already know, which is why your fresh perspective is so valuable.

If something looks weird to you, the core developers may be truly unaware of it. Here's why:

You might using a different browser, operating system, or have different usage habits from the core developer.
They might have been encountered a particular uninformative error message (or unintuitive user interface) so often that it's no longer confusing.
You might be partially colorblind, along with tens millions of people worldwide, but the main authors aren't, so you literally see things differently.

If you can include screenshots and steps for reproducing a bug, that is extremely helpful for the folks fixing it. It turns out even small fixes can make the software a lot more usable for everyone, since everyone appreciates larger and more readable type, comfortable contrast, and an intuitive user interface.

In the Sandstorm community, for instance, before an app author submits an app to the App Market, they often email the sandstorm-dev mailing list with their new Sandstorm package and a link to the source code so the community can try it out and report bugs they encounter and provide UI feedback. I am deeply grateful to everyone on the list who tries out new apps and offers feedback, but I'm especially grateful to Nolan Darilek, who uses a screen reader due to visual impairment, and has given a lot of extremely valuable usability feedback on how a screen reader perceives Sandstorm apps as well as the core itself. Thank you, Nolan.

Organize a meetup

Meetups are a great way for open source community members to learn from each other, make friends, and find collaborators. If there is already a user group for your favorite open source project, you should join it and offer to assist the other meetup organizers.

If there isn't already one, start one yourself! Coordinating with the core team is not required to run a meetup, but for many projects, if you reach out to someone on the community team, odds are pretty good that they'll be happy to help get you started. All else being equal, consider using Meetup.com to organize your meetup group because it's easier for people with related interests to find your group. (Check out this guide to running a Python user group by Asheesh Laroia. And if you're interested in meeting other people who use Sandstorm, you can start or attend a Sandstorm meetup.)

It's OK to start small. I've been to some meetups with fewer than 10 people in a cafe or restaurant, and the cozy atmosphere made it easy for me to actually get to know every person in attendance. I've also been to some that are basically conferences in all but name. Meetups can span a wide range of sizes (after all, some cities have more nerds per capita than other cities), but the number of attendees is not nearly as important as fostering a welcoming and inclusive atmosphere, setting a regular cadence (monthly is pretty good) so that attendees can conveniently calendar it in, and announcing events with at least 10 days of lead time. If you have a venue but forgot to announce it, it's OK to miss a month. Just schedule the next one 40 days in advance so people have something to RSVP for when they go to your meetup page.

If there is already a meetup group, you can offer to assist other meetup organizers. In my experience, the best-run meetup groups always have more than one organizer to share the responsibilities, especially since an organizer can get busy.

There are many ways to help a meetup succeed. Here's a few that might surprise you:

Offer a venue to the organizers. If you're working, there's a chance your employer would be open to making a conference room or event space available to your meetup group in the evening, possibly even with some drinks and snacks. Likewise, if you're a university student or a member of a hackerspace.
Find food/drink sponsors. Recruiting departments have been particularly generous with meetup groups.
Remember there are always new beginners. If you decide to do a different theme for each meetup, it's often a good idea to do a beginner-friendly one every once in a while and give a heads up to meetup groups with adjacent interests.
Visit other similar groups, give talks, and invite them. For example, give a lightning talk about your Meteor app at a MongoDB meetup since your Meteor app is probably using MongoDB by default, and mention the next upcoming local Meteor meetup at the end of your talk.

I'd like to highlight the amazing community organizing work done by Deb Nicholson, such as the inaugural SpinachCon. She also received the O'Reilly Open Source Award for her numerous contributions. I'm also extremely grateful for the hundreds of meetup organizers who tirelessly organize Meteor meetups every month. I'm especially grateful to Oli Evans and Alan Shaw of Tableflip.io, whose Meteor meetup group was the first one to grow into a branch of Meteor Devshop, the official distributed mini-conference for the Meteor community. As a result of the their organizing efforts, two attendees who gave talks at the meetup ended up joining the Tableflip team.

Improve the knowledge base (docs, tutorials, Q&As, etc.)

Occasionally, someone at a meetup will tell me that they got stuck on a problem, searched around and didn't find the answer, and either gave up or implemented some totally hacky workaround. I'll ask if they posted the problem on Stack Overflow, and they'll often say, it never occurred to them to post it or they were embarrassed for having a silly question.

Improving the public knowledge base is a really great way to contribute to open source projects beyond code. This includes things that don't require approval from anyone, such as asking questions on Stack Overflow or mailing lists, or producing blog posts or videos on what you've learned and sending a link of the tutorial to the mailing list. If you've learned a new core concept and are OK coordinating with a review process, or if you found minor errors such as missing links or typos, you should submit suggested edits to the official documentation.

Knowledge is especially useful coming from someone who is relatively new to a project, and who can still remember their state of beginner's mind, while getting their bearings. If you can think of a clearer way to explain something, that's a really great way to contribute! I would probably read, bookmark, and share your tutorial blog post or video. Some of the best educational resources that I've read, bookmarked, or shared, started with a single blog post. And today, the Discover Meteor textbook and the Evented Mind video series are the most popular educational resources in the Meteor ecosystem, for instance.

And if you're stuck don't be embarrassed to ask questions. Personally, I don't believe there are silly questions. Everyone, especially the experts and veterans, takes the journey from not-knowing to knowing. You could be one of today's lucky 10,000. The best way to query information out of the mind of an expert is to ask them, and every time you ask, and the answer is recorded somewhere, where everyone, not just you, will get to see the answer. And experts who aren't the core devs are given an opportunity to share their knowledge. And perhaps, someone more timid than you or less fluent in your language will be so grateful and relieved that you've already asked the question.

Furthermore, improving the knowledge base also has the fantastic side effect of improving the onboarding process of the project, making it easier for more people to contribute. And anything that makes it easier to contribute is especially impactful because it means more hands on deck.

Recruit more hands on deck

The above suggestions are just a few of the myriad ways to contribute to open source projects outside of code contributions, and is by no means an exhaustive list. For further reading on how to foster a more encouraging open source community, I recommend Audrey Tang's Lessons learned from open source communities.

Proprietary/closed software often have entire teams of people working on QA, design, docs, evangelism, recruiting, onboarding, and every conceivable role outside of engineering. But because engineers have a strong tendency to spread the word to other engineers over anyone else, many open source communities have a tendency to be relatively short-handed in non-engineering skill sets, like design and community organizing.

So let's solve this short-handedness problem together, by 1) getting more hands on deck, 2) have everyone (from casual users to core contributors) pitch in on more than code, and 3) foster a welcoming atmosphere that appreciates all contributions, not just code contributions. Promote your favorite open source project in venues beyond engineering-heavy circles by giving a lightning talk at a design meetup, or reaching out to friends and acquaintances.

And if you're on the core team of a project, be sure to thank and acknowledge all contributors, not just code contributors. Just think of how much more polished your project would be with that many more random little bugs reported and fixed, with improved graphics and UI, if only those potential contributors knew the extent to which their help is appreciated.

If you share this blog post with a friend with pixel/people/prose/other skills and introduce them to an open source project who can use their help, or have advocated using open source software at work amongst your colleagues, you have done something remarkable. And for that, thank you.