What I’ve learned about open source community over 30 years

I’ve been part of open source software communities for a long time. I’ve made some mistakes in that time, but I’ve learned a lot too. One project I’ve worked on is the FreeDOS Project, an open source implementation of the original DOS operating system. We started FreeDOS in 1994, and it’s still going. In fact, we celebrated 30 years of FreeDOS on June 29, 2024. That’s a major milestone for any open source software project!

I’d like to share my journey and what I’ve learned about working in the open source community for over 30 years.

I started with DOS

If you don’t know about FreeDOS, let me briefly set the clock back to the 1980s. When IBM sold their first IBM Personal Computer 5150 in 1981, they needed an operating system to run on it. IBM contracted with Microsoft, who in turn worked with Seattle Computing Products, to provide a Disk Operating System (“DOS”) for the IBM PC.

For more than a decade, DOS was the dominant desktop operating system. It ran well on low-end hardware, and grew to include support for larger storage and memory. And DOS had thousands of great applications and games. If you could imagine it, someone probably had an application to do it. Anyone from the era likely remembers desktop word processors like WordStar, WordPerfect, and PC-Write – or spreadsheet applications including VisiCalc, Lotus 1-2-3, and Quattro Pro.

I grew up with DOS, from 1981 with the IBM PC until my undergraduate days at university. I loved using DOS, especially the command line, which I found to be quite flexible. And as I learned C programming, I was able to create my own tools to extend the functionality of the DOS command line.

But when Microsoft decided to stop making new versions of DOS, I decided it was time to create our own open source DOS. On June 29, 1994, I announced a project to do just that. Initially called “PD-DOS,” we soon renamed the project to “FreeDOS” to reflect the free software and open source goals of making our own DOS. On June 29, 2024, the FreeDOS Project will celebrate 30 years in open source.

Lessons in open source community

As the project coordinator for FreeDOS, I like to think I’ve learned a few things about how to keep an open source community going. Here are a few lessons I’ve learned in maintaining an open source project for so many years:

(1) It’s more than just code. An open source project needs to be grounded in its community. An open source project goes nowhere if it is closed to new ideas or discourages new development.

That means you need to be open to communication; if someone brings forward a new idea that doesn’t fit the initial goals of the project, don’t dismiss it out of hand. Consider if that new idea could open new features or ways of doing things. It could be the spark that brings a cool new feature to the project.

(2) Keep people engaged. As the project coordinator, I try to keep people engaged. This can come in many forms, the most basic of which is recognizing developers who have contributed to the project in some way, such as adding a new feature, fixing a bug, or making a new release.

But engagement is also about finding other ways to recognize people. For example, in the last several years, we’ve celebrated our community by publishing interviews and ebooks with their reflections on FreeDOS. More recently, we’ve also hosted virtual get-togethers, where we can get to know each other as more than just an email address.

(3) Maintain a website. Every open source project needs to have a website. It doesn’t need to be a great website, but you need a website to provide a virtual “home base” for the project. The first thing that new users will do when they hear about your project is visit your website. The website is a great opportunity to share news about what’s happening, such as new versions. Also consider applying a consistent look and feel to your website, and provide lots of screenshots to show what the program looks like and what it can do.

I recommend refreshing the website every year or so. That doesn’t mean a complete overhaul of the website and its content, but use that opportunity to re-examine the website navigation. Over time, as you need to add more information to the website, you might simply tack on a new page or “info box” without considering how users will find it. By refreshing the website once a year, you can clean up any website “cruft” and keep things organized.

(4) Share great news. In addition to the website, consider other ways to raise awareness about your open source software project. In the FreeDOS Project, we’ve found that posting videos to our YouTube channel is an excellent way to help people learn about FreeDOS, what it is, how to use it, and what you can do with it. As the project coordinator, I also like to write articles about FreeDOS for websites. The more information you can share about your open source project, the more people will find it familiar and want to try it out.

(5) Maintain open lines of communication. Open source projects need to maintain open communication. This can take many forms, including an email list, discussion board, or some other discussion forum. Other forums where people can ask more general “Help me” questions are okay, but try to keep all discussion about project development on your official discussion channel.

For example, the FreeDOS Project has two email lists, freedos-devel and freedos-user, where most FreeDOS developers hang out. This is where we discuss topics that affect the project, announce new versions of FreeDOS programs, and gain consensus about new things we might do or changes to make to FreeDOS. But we also have a Facebook group where other users prefer to ask questions along the lines of “How do I run X program on FreeDOS.” Some FreeDOS developers are also on Facebook, but we are clear that the email lists are where we make our decisions.

(6) Keep it respectful. Open source software communities need to set expectations for respectful communication with each other. The best way to make these “ground rules” clear is to publish a code of conduct about what is and is not acceptable behavior. We publish our code of conduct on our website.

(7) It’s about the code, too. An open source project isn’t really open source without source code that everyone can download, study, use, modify, and share. Be sure your project has selected a recognized open source license that meets your goals. For example, every program that we included in FreeDOS – including the kernel, command.com shell, and utilities are distributed under the GNU General Public License or a similar open source and free software license.

Celebrating 30 years in open source

30 years is a long time for any open source project, especially for a retrocomputing operating system like FreeDOS.

But it’s all because of the great developers and users in our community. In celebrating FreeDOS, we are really celebrating everyone who has created programs, fixed bugs, added features, translated messages, written documentation, shared articles, or contributed in some other way to the FreeDOS Project.

Thank you to Pat Villani who wrote our first kernel, and the long list of people who maintained the kernel afterwards, including John Price, Bart Oldeman, Tom Ehlert, and Jeremy Davis. really thanks to developers and users like Tim Norman, M. Hannibal Toal, Eric Auer, Martin, Arkady, Bernd, Charles, Eduardo, Rene, Dave, Mike, Aitor Santamaria, Tom, Paul Vojta, Joe Cosentino, Shaun, Till, Wilhelm, Rugxulo, Mateusz Viste, Gregory Pietsch, Imre, Louis, Fritz, Jim Tabor, Jason, Jerome Shidel, Ron, Lucho, ror4, Steffen, Ralf Quint, and the many many others who have been part of our community. Here’s looking forward to more years to come!

This article is adapted from What I’ve learned about Open Source community over 30 years by Jim Hall, and is republished on Both.org by the author.