Last Updated on July 6, 2025 by David Both

Author’s note: This article is excerpted in part from chapter 25 of my book, The Linux Philosophy for SysAdmins, with significant changes to update the information in it and to better fit this format.

Linux and a very large proportion of the programs that we run on it are open source programs. Many of the larger projects, such as the kernel itself, are supported directly by foundations set up for that purpose, such as the Linux Foundation, and/or by corporations and other organizations that have an interest in doing so.

As a SysAdmin I write a lot of scripts and I like doing so but I am not an application programmer. Nor do I want to be because I enjoy the work of a SysAdmin which allows for a different kind of programming. So, for the most part, contributing code to an open source project is not a good option for me. There are other ways to contribute and I use those options. This article will help you explore some of the ways in which you might contribute.

Code

Just because I choose not to contribute code to open source projects does not mean that you should avoid it also. I know that many SysAdmins are excellent programmers and could be very helpful to one or more of the hundreds of open source projects out there. Without the coders there would be no projects in the first place.

Projects can have teams of developers ranging from large quite small, sometimes with only a single developer. Different coding languages are used in different projects. Many projects are coded in C or C++ while others use interpreted languages such as Perl, PHP, Python, Ruby, bash, or other shell scripting languages.

Whatever your skill level, you can find a project that has plenty of tasks for you to work on.

Test

After the code is written, someone needs to test it. Testing is just as important as writing the code is in the first place.

Some projects need dedicated testers who take code as soon as it is completed by the developer and run it through a series of formal tests. This is very similar to half of my responsibilities when I worked at Cisco. This type of testing requires writing a formal test plan and then systematically working through the plan. Failed tests are reported back to the developers to fix.

Submit bug reports

Submitting bug reports is a very important way to support an open source project. I have done a few of these and it is easy to do.

Most projects have well-defined and documented methods for reporting bugs. Many projects use Bugzilla for reporting bugs and some use other tools including some home grown ones, or even just emails to the developers. The details of how to submit bugs are usually found through a link on the project home page.

In this case we are not talking about beta testing as in the previous section. Here we are using final release code that has passed all of the alpha and beta testing that could be devised to test it. This is real world, “test in production,” type of testing; because production is the best and final test.

When when find a bug in a production product, even though this is not be part of an official test program of any type, it is incumbent upon us to submit a bug report to the project. Almost every project as some means of reporting bugs.

Documentation

Documentation is an area where many of us can participate regardless of whether we code or not. Although there are many jokes about people not reading the documentation ( RTFM ), the documentation is very important. Documentation can range from man pages for command line utilities and tools, to complete on-line manuals for large applications such as that for LibreOffice. LibreOffice has a series of well written manuals that can be downloaded as PDF files or used on-line with your browser.

For those of us who like to write, creating and maintaining documentation can be an excellent way to contribute.

Assist others

Assisting others is another great way to support open source software. This type of participation offers many different options.

One option is to participate in local meetups where open source enthusiasts discuss the advantages of open source with people who are unfamiliar with it. In many of these meetups, sometimes called install fests, the experienced users help the noobs install Linux and get started with the basics. Another option is to simply introduce your friends and family to Linux and help them get started. Some Linux users like to hang out on various forums and IRC chat rooms to help people by answering questions.

Teach

I like teaching. I am good at it according to the course evaluation forms I have received over the years. Since I started as a Course Development Representative at IBM in 1978, I have taught a lot of different courses for both hardware and software.

If you are so inclined, and you have some skills in doing presentations, teaching may be a good fit for you. The sessions may range from an hour in length or a week. At two of my employers I did hour-long Lunch’n’Learn sessions that were just overviews of various parts of Linux and other open source software. At other places I did one or two day classes that were intended to introduce Windows admins to some basic Linux commands and things like filesystems.

Write

I also like to write. This book is only one of my writing projects, the others being my frequent articles for Opensource.com and my own web sites. The Both.org web site is my attempt to record things I have learned that were hard to find. I also find it a good place to share some of my many opinions.

I wrote many articles for Opensource.com, while its was still active, most of which are mostly deep dives into some important subjects such as filesystems, various server software, desktops, and other Linux and open source software. I’ve since moved many of my articles and written hundreds of new one for Both.org.

Writing articles and books that help SysAdmins and others who want to be SysAdmins is my own primary means to give back to the open source community and also to provide some level of mentoring even if it is at somewhat of a remove from the intended recipients.

Here again, if you are good with the written word you may find that writing about Linux and open source is a good way for you to help. We’d love to have you submit your articles to us. Find out more here.

Donate

Finally, most projects accept monetary donations. At first glance, this would seem to be a rather crass, hands-off way of providing support for an open source project but all projects need monetary support. I have chosen three to which I contribute a bit of money from time to time.

Because of its importance in my day-to-day work, I support LibreOffice¹ with small donations. I also support a couple of the high-level organizations. I donate to the Linux Foundation² because they support Linux infrastructure, they directly support Linus Torvalds by paying him to continue his work on the kernel, and they support other open source communities that are important to its well-being and growth. I also donate to the Open Source Initiative³, which is responsible for approving various licenses and certifying that they comply with open source principals.

There are many other open source organizations and projects that are in need of funding. Your monetary donation can directly support the work of those who at the forefront of the open source movement.

Thoughts

Open source is all about contributing in one way or another. My primary contributions have been in teaching and writing. I like doing both of those things and I am good at them.

I am not going to list a bunch of projects here. The primary reason is that there are too many and I would certainly miss some. Any such list printed here would be a snapshot at a point in time. I have simply listed a very few that I support at the time of this writing.

So if you want to support a project, pick one that you are familiar with and that has made a difference for you, locate its home page, and find out there how to contribute in some way that makes sense for you.

1. LibreOffice web site, Support LibreOffice, https://www.libreoffice.org/donate/ ↩︎
2. Linux Foundation, Donate to The Linux Foundation, https://www.linuxfoundation.org/about/donate/ ↩︎
3. The Open Source Initiative, Donate, https://opensource.org/civicrm/contribute/transact?reset=1&id=2 ↩︎

.

This is the complete list of all the articles in this series.

1. What is the Linux Philosophy for SysAdmins?
2. Data Streams, the universal interface
3. Transforming Data Streams
4. Everything is a File
5. Use the Linux FHS
6. Embrace the CLI
7. Be the Lazy SysAdmin
8. Automate Everything
9. Always use shell scripts
10. Test Early, Test Often
11. Use common sense naming
12. Store data in open formats
13. Use separate filesystems for data
14. Make programs portable
15. Use Open Source software
16. Strive For Elegance
17. Find the simplicity
18. Use your favorite editor
19. Document everything
20. Backup everything frequently
21. Follow your curiosity
22. There is no should
23. Mentor the young SysAdmins
24. Support your Favorite Open Source Project
25. Reality Bytes