95

I really like a specific open source project and would like to contribute to it. Unfortunately I don't know anything about programming. What are meaningful ways in which a non-programmer can contribute in a meaningful way to an open source project?

Philipp
  • 11,880
  • 2
  • 30
  • 52
  • 19
    It's hard to resist the urge to suggest learning how to program. – Pharap Jan 01 '16 at 04:30
  • 25
    If you know more than one national language, then consider providing translation for a project that is used widely. Git has a translation team that is separate from the programming team. Ubuntu has a similar translation effort. – Philip Oakley Jan 01 '16 at 11:37
  • 7
  • 4
    Many of the answers below list great points, but there's one little tweak: You can be a programmer, and you can still help out in the ways that people have mentioned below. The trick is to contribute to a project in a way that you are confident in your work, and that you feel like you can help out :) – Zizouz212 Jan 03 '16 at 16:44
  • I wrote an article on this: http://blog.smartbear.com/programming/14-ways-to-contribute-to-open-source-without-being-a-programming-genius-or-a-rock-star/ – Andy Lester Jan 04 '16 at 19:37
  • 2
    @Pharap: It may be hard, but I do hope the urge is resisted nonetheless. Programming is an engineering discipline, and like any other field of engineering it requires years of experience and domain knowledge to do well. It may be a bit odd to imagine constructing an open-source hotel, but it's not completely out of the realm of possibility. But even if someone did do that, just imagine if some guy with no experience in construction came up to the guys running the hotel project and said "I really admire what you're doing here; here are some ideas that I came up with after a month of study." – Mason Wheeler Jan 04 '16 at 20:01
  • 1
    To be clear, I have nothing at all against someone being inspired by software to learn to program. That's how I got started, but that was as a young child 25 years ago. I've dedicated the bulk of my life to mastering the craft, and along the way I've seen the ugly results of a lot of mistakes made by people who didn't know what they were doing. A bunch of them were my own, back before I knew what I was doing, and I know I wouldn't want Young Me contributing to the projects I'm working on today; not before he's taken the time to learn enough to become Modern Me. – Mason Wheeler Jan 04 '16 at 20:11
  • @MasonWheeler That happens with a fair number of open source projects anyway. And the more popular open source becomes, the more it will happen, projects being created and contributed to by people who have barely scratched the surface of a single paradigm. Side note, I envy people who've had technology in their lives since a very young age. 3-4 years ago I didn't know the difference between a megabyte and a gigabyte, now I know 5 different programming languages (two of them almost inside out). I can't help but think how much more I could have achieved with an earlier start. – Pharap Jan 05 '16 at 08:04
  • If you don't have the requisite skills to help in a good cause, you can use the skills you do have in your day job, and donate (often tax free) to charitable foundations. This goes for any cause, not just open source. – Ben Jan 06 '16 at 10:58
  • @Ben, all open source projects, once they become large enough, need all sorts of "day job skills", even ones not obviously visible. On the other hand, OP might want to relax doing something (a bit, or a lot) different from "day job". – vonbrand Jan 12 '16 at 18:18
  • What opensource project are you exactly thinking about? You should mention it in your question to get more focused answer! – Basile Starynkevitch Jan 27 '16 at 13:51
  • I'm closing this question as too broad, because it is, in effect, a list question. I had actually meant to close this a long time ago, after the activity had seriously settled down, but my rationale behind doing this came after community discussion in chat. – Zizouz212 Mar 10 '16 at 01:35

8 Answers8

129

There are lots of things to do around open source projects which do not require any programming knowledge at all. Among them are things like:

  • User Documentation: Programmers love writing code but hate writing documentation. And if we like to write documentation it's mostly the technical documentation for other developers. As a result, many open source projects have a user documentation which is hard to understand for non-technical users, full of gaps and in many places out of date. As an experienced user you can help to keep the documentation useful.
  • User Support: Programmers are already very busy programming, so they are glad about people who keep the newbies off their back by answering their questions. This goes hand-in-hand with user documentation, because by listening to the user's problems you learn where the documentation needs to be improved.
  • Artwork: Do you have artistic talent? Then you could work on the art assets of the project like icons or logos. Not just the software itself but also its website and promotional material can certainly benefit from your skills.
  • Internationalization: Are you fluent in a different (non-programming) language than the primary language the developers communicate in? Then you can help with translating the software and its documentation into that language.
  • Making good bug reports: We can only fix issues we are aware of. Unfortunately many bug reports we receive from users are of very poor quality. To fix a bug we must know exactly what steps must be taken to reliably cause the bug to happen. When you take the time to research a bug, isolate the exact conditions which make it appear and provide us with exact instructions, you can save us a lot of time.
ArtOfCode
  • 9,396
  • 2
  • 28
  • 70
Philipp
  • 11,880
  • 2
  • 30
  • 52
  • 21
    All five of these points are very valuable. Many open source projects are more likely to fail from a lack in these areas than in the programming itself. – Basil Bourque Jan 02 '16 at 01:38
  • 3
    Good answer. I'd just add that "Documentation" help can be as simple as improving or adding to the project's Wiki pages. – user_1818839 Jan 02 '16 at 15:35
  • 19
    A note on good bug reports, if you see a bad one, trying to reproduce it, then leave a proper report on the same thread as the bad one helps immensely. – RubberDuck Jan 02 '16 at 16:24
  • 4
    It's worth noting that a lot of open source software consists of frameworks and libraries for other programmers to use, in which case the documentation, support and bug report bullet points would still require some basic programming ability. But for open source end-user applications this list is spot on, +1. – Ixrec Jan 02 '16 at 21:44
  • 3
    +1 for artwork, artwork, artwork. It happened to me that I had ideas which I could code, but couldn't find anyone to do a proper artwork for, so ultimately the project was abandoned. – vsz Jan 03 '16 at 17:21
  • 8
    It should be stressed that the last point does not apply only to own bug reports, but also to the bug reports made by others. Go through the list of new bugs and try to understand and reproduce them. Where you can, confirm them and provide additional details as appropriate, where you can't, try to get further details from the original reporter. And merge any duplicates. This is called triage and is extremely helpful. – Jan Hudec Jan 04 '16 at 07:55
  • 2
    I'd add "Tutorials, training videos etc" to this - learning resources are hugely important. Documentation is good, tutorials are often better. – Jon Story Jan 04 '16 at 16:45
  • 2
    There is also community management, project management and the likes. If you are good at organizing stuff, you can also volunteer to help for the project's conferences or workshops. If there is a forum or mailing list, you can offer time to moderate that. Or you can do marketing and help secure funding or increase standing of the project in its respective larger community ecosystem. Those are the things that tech people usually lack. – simbabque Jan 05 '16 at 10:39
44

Testing.

You don't have to be a programmer to test a program. Use the program as it's designed to be used, but also use the program at the extremes or with "corner cases" to try to break it. In either case keep detailed notes as you work so when it breaks or misbehaves you know how you got there and can make it happen again. Conscientious programmers will love you ( I say this as a programmer) if you can give them a reproducible bug where there are clear steps on how to make it happen.

Make your bug reports programmer-friendly: A clear description of the bug, a clear (hopefully simple) set of instructions on how to make it happen, a complete description of the environment (OS, versions, hardware, whatever) and any necessary files or data.

user316117
  • 541
  • 3
  • 2
  • 8
    +1 for this. Testing is a very different skillset than programming, and (also speaking as a developer) good testers are worth their weight in gold. Just remember the most important rule of bug reporting: reproducibility. If I can't make the bug happen on my end, it doesn't matter what's going on at your end, because I can't fix it if I can't find it. So give me details; tell me exactly what you were doing. If you got an error message, copy-paste it into the report directly, in its entirety; don't just say "I got an error message." If necessary, add screenshots or even screencap videos. – Mason Wheeler Jan 04 '16 at 20:06
  • 2
    Absolutely agree. Though it might depend on the project. Many open source projects are very weak on testing; paradoxically, that's where it's most difficult to contribute, because creating a good test environment is a significant engineering challenge and needs a lot of programming experience. But if a test environment exists, then populating it with lots of well thought out test cases is something that doesn't necessarily (again, depending on the project) need strong programming skills: just methodical thinking. – Michael Kay Jan 05 '16 at 19:42
  • Testing and generating test case can be painful. Especially for small teams. It would be very helpful to have someone that is outside the code to generate samples, especially if they can come up with cases that the software could not handle. – Jamie Mar 31 '16 at 07:21
22

You might want to check out e.g. Fedora's page on how and for what to join. You'll see plenty of tasks for non-programmers. Some of the highly regarded members of the Fedora community don't do any programming.

Fedora looks for people interested in content writing (tutorials, write articles for their magazine, documentation in general), design (artwork, flyers, icons), development (programming, bug fixing, package maintenance), people contact (give talks, help recruiting new members, mentoring), translators (help with i10n in general), web development and administration (develop and keep the web presence of the project running). Those are just some of the tasks listed, and there are clearly other specialized rôles that are welcome.

You'll probably find similar calls elsewhere.

Disclosure: I'm a long time Red Hat and then Fedora user, currently an Ambassador for Chile, part of the "people contact" crowd.

vonbrand
  • 5,267
  • 1
  • 13
  • 30
14

An addition to @Philipp's answer is developing User Interfaces (UI's). A lot of programmers are absolutely terrible at designing good user interfaces, and know it. If you are good at such things, many would likely be delighted to have a designer to plan their UI's so they just have to implement them.

13

One of the greatest assets are people experienced in web design/development.

I find that this can be incredibly underestimated: websites are the platform for many projects to advertise. But they are also relatively underused. While some projects such as Github Pages make the job easier, it can be very hard to have a site that is both unique and attractive, while also serving its primary goal: to advertise the project.

Many websites need a great deal of effort, and it's an effort that many developers don't want to put, or don't have the time to put. For prospecting end users of a project that may take the project themselves and use it, the website is the place where a list of features can be culminated with. No developer will look at the code base just to figure out what a project does.

"Website Builders" such as Google Pages, Github Pages, or Wix offer templates, which can be difficult to extend with designs of your own, or with other functionality. Projects such as Django can also be difficult: it may involve learning another programming language, or familiarizing yourself with another code base, which can be very time-consuming.

This is also arguably a project within the project. But the asset of a proper website will assist you, and others in having a clean, central place to discuss ideas, present yourselves, and to collaborate. They can host your documentation, community resources, contributor resources and more.

Here's some attractive sites for various projects (you'll see the difference):

Sites may arguably be better for more-used projects, but the benefits of a site can be applied for any project, big or small.

Zizouz212
  • 6,449
  • 4
  • 36
  • 75
13

There's one thing that I hadn't seen proposed yet: ideas. You might actually have some good ideas that can be discussed on the project's mailing list and end up getting implemented - the more thought over, the better. By not being a developer you're more likely to be the "regular user" kind of man and you can use it to your advantage by proposing things that you would like to see.

Another activity that comes to my head is advertising. Write a blog article and post it to Slashdot and Hackernews. Find related StackOverflow questions and make people aware of the tool if it's programming related (or do the equivalent thing if it's not). Write a Wikipedia article. All of those can help people find the project.

d33tah
  • 383
  • 1
  • 9
  • 13
    Yes and no. Ideas are a dime a dozen, doing the work to see if they are worthwhile, ironing out the inevitable quirks, and deploying them is where the value lies. Sez Edison: "Genius is 1% inspiration and 99% perspiration". – vonbrand Jan 02 '16 at 17:24
  • I think that this is really project specific though: For projects of a specific nature, like Python-Requests, ideas aren't as valuable because the project needs to follow a specification, and it's in more of a niche region unlike something like Python-Django where ideas can't grow into new themes and features. Otherwise, you make good points. – Zizouz212 Jan 02 '16 at 19:47
  • 1
    Added the advertising. – d33tah Jan 02 '16 at 22:32
12

Since the Phoenicians invented money, one of the possible answers is clear. Many open source projects has a possibility to donate.

z100
  • 137
  • 2
  • 2
    Okay, so... I donate money to a project. Then what happens? It would be helpful if you could elaborate how an open source project could utilize donations from anyone. – Zizouz212 Jan 04 '16 at 22:17
  • 3
    They usually explain that they would do with your money – x64 Jan 05 '16 at 13:10
  • 1
    @h22 Doesn't really matter. The answer could definitely be improved if they shed some light on that matter. – Zizouz212 Jan 05 '16 at 21:12
  • 2
    This. If you don't have the requisite skills to help in a cause, you can use the skills you do have in your day job, and donate (often tax free) to charitable foundations. This goes for any cause, not just open source. – Ben Jan 06 '16 at 10:57
6

UI specialist: you could download the open source software and tell devs what problems you have with it (is it easy to install, etc.). You could even make a Google Survey about if users who installed or used the software have ideas on what was hard to do and what made sense to them. If you have a background in psychology or sociology UI studies will be perfect for you.

Thomas Shera
  • 161
  • 2