Please consider adding [email protected] to your address book, which will ensure that our messages reach you and not your spam box.

Read and share online: https://www.fsf.org/blogs/sysadmin/thank-you-for-supporting-the-fsf-tech-team

Dear Free Software Supporter,

I'm Ian Kelling, a member of the Free Software Foundation (FSF) tech team. First of all, I'd like to express our deep gratitude on behalf of the whole FSF staff for the overwhelming support we received during the recent matching campaign. A big thank you to all who helped us raise a total of $46,500 in contributions and matching gifts. Meanwhile, we hope to keep the momentum going, so that we also reach the year-end fundraiser goal of $375,000 by December 31.

I'm writing to you today to share some of what the tech team has been working on, what our plans are, and a little personal perspective.

I have a twelve-year-old at home, and I asked her: "What should I tell people about free software, and why the FSF is worth supporting?" She immediately responded: "Tell them free software is like having free will. You are free to decide." I'd never heard that, but I think that is a cool way of putting it. I'd elaborate further that we get to individually and collectively decide how we run, modify, learn from, and share the software.

The FSF tech team is working hard to make free software the norm, so that the most widely used software would not be the hundred shades of malware they are now, but would instead respect the user's, i.e. your, freedom. It's a big job. We operate sixty-three different services, platforms, and websites. We maintain all the computers and software FSF uses, including obscure things like accounting software, Asterisk telephony software, many websites such as fsf.org, gnu.org, and endsoftwarepatents.org, all with a wide variety of web frameworks. We also provide critical services to the GNU Project, like email, build servers, release hosting, bug tracking, Git hosting, and provide servers to free software projects like KDE, Replicant, Trisquel, and Parabola, all on computers with free BIOSes.

There are thousands of GNU and non-GNU developers relying on the services we run, and billions of GNU software downloads. We even run software to participate in the Border Gateway Protocol (BGP), an Internet protocol for routing Internet traffic.

Since I started at FSF, I've encouraged us to take the time to be more public in our sysadmin work while still being mindful of the overhead that doing so can add. To that end, we recently published 133 webpages of our sysadmin documentation. These are only a fraction of the notes we keep, and they're far from perfect. But they offer a glimpse into the work we do and what it takes to administer the software and hardware of the FSF, all while avoiding proprietary software to the maximum extent possible. Something especially interesting to browse is the "tickets" section, which documents how to handle sixty specific issues that we have experienced. A lot of what is written there are shell commands which we run in Bash.

GNU Bash is a wonderful tool we use every day, it executes commands typed into the terminal and is also a scripting language. FSF system administrators have had varying degrees of Bash knowledge, including interns and volunteers who are just getting started with Bash. We have quite a few Bash scripts which are ugly and which don't use best practices, but for the job they do, they are sufficiently reliable and that's okay. We aim to get the job done, not be perfect. But we also have a healthy drive to master our craft, and so, toward this end, we recently published an FSF Tech Team Bash Style Guide.

This style guide is similar to existing ones, but it has one difference worth highlighting: it explains how to use automatic error handling while avoiding pitfalls where errors are ignored or don't give useful information. This includes, optionally, using a stack trace library, one written by us, that makes it practical to use functions with automatic error handling. Most Bash guides suggest using automatic error handling without mentioning that pitfalls exist. For example, Greg's Wiki, the most comprehensive Bash guide, simply recommends against using it because pitfalls exist, without trying to list them. I think our guide expands on even the most comprehensive sources and can help those looking for more information.

This fall fundraiser is different than any of the past ones I've participated in. My fellow team member Andrew Engelbrecht just moved on from the FSF in October after seven years on staff and several more as a volunteer doing invaluable work for the FSF. I'm grateful he wrapped up a lot of work before he left. That being said, currently it's just Michael and myself on the tech team. Because of economical challenges and inflation, we will not be hiring someone to join the tech team until we turn things around financially as an organization. Doing this work with a two-person tech team will be more challenging. Your support means a lot to me and everyone at the FSF.

If you want this work to continue, please give generously! Will you help us reach our year-end fundraising goal of $375,000 by making a donation or joining as an associate member before December 31? Your contribution will ensure that the tech team can continue its important work and finish projects like the new FSF website, GNU mailing list upgrades, ftp.gnu.org backend software improvements, updates to debbugs.gnu.org, LibreJS spec changes for easier JavaScript identification, and more.

I think the FSF-run GNU infrastructure is a great example of free software that's both for the users and funded by the users. This work is real-life proof that the concepts of free software, conceived forty years ago, are manageable in practice, as long as people believe in them. Now is the time to show us that you do. And, as my daughter put it: free software is like having free will. Let's fight for that future!

Thank you for supporting the FSF tech team!

Happy hacking,

Ian Kelling
Senior Systems Administrator