Quite often I get asked how someone can get involved with an Open Source project without or at least minimal development skills. I have some experience in this topic as I am pretty involved with some projects, especially Icinga and Foreman, and mostly not because of my development skills which are existing but at least lack more exercise. So here comes my non exhaustive list of roles a non-developer can engage in a project.
A good point to start is talking about the project. I know this sounds very simple and it is indeed. Spread the word about what you like about and how you use the project and by doing so you help to increase the userbase and with increasing userbase there will be also an increase in developers. But where to start? The internet gives you many opportunities with forums, blogs and other platforms or if you prefer offline communication you can go to local computer clubs, join a user group meeting, help at a conference booth or even send in a paper for a conference. And let the project know about so they can promote your talk.
Another option for getting involved quite easily is bug reporting. If you start using some software more and more, time will come and you will find a bug so simply report it. Try to find a way to reproduce it, add relevant details, configs and logs, explain why you think it is a bug or missing feature and developers can hopefully fix it. When you like the result and you want to get more involved start testing optional workflows, plugins or similar edge cases you expect to be not well tested because they have a smaller user base. Another option is testing release candidates or even nightly builds so bugs can perhaps be fixed before they hit the masses. If provided take part in test days for new features or versions and test as many scenarios as you can or even go a step further and help organizing a test day. With minimal development know-how you can even dig into the code and help with fixing it, so it is also a good idea if you want to improve this knowledge.
If the user base of a project grows, the number of question that are asked every day grows. This can easily reach a number the developers have to spend more time on answering questions than on coding or have to ignore questions, both can cause a project to fail. Experienced users providing their knowledge to newbies can be a big help. So find the way a project wants this kind of questions to be handled and answer questions. It can vary from mailing lists, irc and community forums or panels to flagging issues as questions or if no separate platform is provided community may meet on serverfault, stackoverflow or another common site shared by many projects. Also very important is helping routing communication in the right channel, so help new users also to file a good bug report or tell people to not spam the issue tracker with questions better handled on the community platform.
Projects lacking good documentation are very common and also if the documentation is good it still can be improved by adding examples and howtos. Pull requests improving documentation are likely to be accepted or if the project uses a wiki access is granted, but if you feel more comfortable creating your own source of documentation by writing howtos in your private blog or even creating video tutorials on youtube. Many project will link to it at least in community channels if you let them know about.
Improving user base by making the software available to more people by providing it in additional languages is always a good thing. But perhaps everyone knows at least one project where selecting a language other than English feels like automatic translation, mix of languages or you would have chosen just different words. Already with some basic knowledge of the software and a feeling for your native language you can help improving translation. In the most cases you do not need special knowledge of tools or translation frameworks as projects try to keep barriers low for translators.
When projects grow they will need more and more infrastructure for hosting their website, documentation, community platform, CI/CD and build pipeline, repositories and so on. Helping with managing this infrastructure is really a good way to get involved for an ops person. Perhaps it is also possible to donate computing resources (dedicated hardware or a hosted virtual machine) what will be often honored by the project by adding you to the list of sponsors giving you some good publicity.
Nowadays a project is not only about the software itself, making installation more easy by providing packages and support for configuration management or more secure by providing security analyses, hardening guides or policies is something system administrators are often more capable than developers. From my experience providing spec files for RPM packaging, Puppet modules or Ansible roles to support automation or a SELinux policy for securing the installation are happily accepted as contribution.
Like I said this list is probably not complete and you can also mix roles very well like starting with talking about the project and filing bugs for your own and perhaps end as community supporter who is well-known for his own blog providing in depth guides, but it should at least give some ideas how you can get involved in open source projects without adding developer to your job description. And if you are using the project in your company’s environment ask your manager if you can get some time assigned for supporting the project, in many cases you will get some.
Autor: Dirk Götz
Dirk ist Red Hat Spezialist und arbeitet bei NETWAYS im Bereich Consulting für Icinga, Puppet, Ansible, Foreman und andere Systems-Management-Lösungen. Früher war er bei einem Träger der gesetzlichen Rentenversicherung als Senior Administrator beschäftigt und auch für die Ausbildung der Azubis verantwortlich wie nun bei NETWAYS.