{"id":7601,"date":"2024-12-08T03:00:00","date_gmt":"2024-12-08T08:00:00","guid":{"rendered":"https:\/\/www.both.org\/?p=7601"},"modified":"2024-09-13T21:08:45","modified_gmt":"2024-09-14T01:08:45","slug":"what-ive-learned-about-open-source-community-over-30-years","status":"publish","type":"post","link":"https:\/\/www.both.org\/?p=7601","title":{"rendered":"What I\u2019ve learned about open source community over 30 years"},"content":{"rendered":"
\r\n
\r\n \r\n <\/i>\r\n <\/a>\r\n <\/span>\r\n<\/div><\/div>\n

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<\/a> on June 29, 2024. That’s a major milestone for any open source software project!<\/p>\n\n\n\n

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

I started with DOS<\/h2>\n\n\n\n

If you don\u2019t 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 (\u201cDOS\u201d) for the IBM PC.<\/p>\n\n\n\n

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.<\/p>\n\n\n\n

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.<\/p>\n\n\n\n

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 \u201cPD-DOS,\u201d we soon renamed the project to \u201cFreeDOS\u201d 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.<\/p>\n\n\n\n

Lessons in open source community<\/h2>\n\n\n\n

As the project coordinator for FreeDOS, I like to think I\u2019ve learned a few things about how to keep an open source community going. Here are a few lessons I\u2019ve learned in maintaining an open source project for so many years:<\/p>\n\n\n\n

(1) It\u2019s more than just code.<\/strong> 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.<\/p>\n\n\n\n

That means you need to be open to communication; if someone brings forward a new idea that doesn\u2019t fit the initial goals of the project, don\u2019t 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.<\/p>\n\n\n\n

(2) Keep people engaged.<\/strong> 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.<\/p>\n\n\n\n

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

(3) Maintain a website.<\/strong> Every open source project needs to have a website. It doesn\u2019t need to be a great website, but you need a website to provide a virtual \u201chome base\u201d 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\u2019s 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.<\/p>\n\n\n\n

I recommend refreshing the website every year or so. That doesn\u2019t 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 \u201cinfo box\u201d without considering how users will find it. By refreshing the website once a year, you can clean up any website \u201ccruft\u201d and keep things organized.<\/p>\n\n\n\n

(4) Share great news.<\/strong> In addition to the website, consider other ways to raise awareness about your open source software project. In the FreeDOS Project, we\u2019ve 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.<\/p>\n\n\n\n

(5) Maintain open lines of communication.<\/strong> 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 \u201cHelp me\u201d questions are okay, but try to keep all discussion about project development on your official discussion channel.<\/p>\n\n\n\n

For example, the FreeDOS Project has two email lists, freedos-devel<\/strong> and freedos-user<\/strong>, 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 \u201cHow do I run X program on FreeDOS.\u201d Some FreeDOS developers are also on Facebook, but we are clear that the email lists are where we make our decisions.<\/p>\n\n\n\n

(6) Keep it respectful.<\/strong> Open source software communities need to set expectations for respectful communication with each other. The best way to make these \u201cground rules\u201d clear is to publish a code of conduct about what is and is not acceptable behavior. We publish our code of conduct<\/a> on our website.<\/p>\n\n\n\n

(7) It\u2019s about the code, too.<\/strong> An open source project isn\u2019t 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<\/a> that meets your goals. For example, every program that we included in FreeDOS – including the kernel, command.com<\/strong> shell, and utilities are distributed under the GNU General Public License or a similar open source and free software license.<\/p>\n\n\n\n

Celebrating 30 years in open source<\/h2>\n\n\n\n

30 years is a long time for any open source project, especially for a retrocomputing operating system like FreeDOS.<\/p>\n\n\n\n

But it\u2019s 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.<\/p>\n\n\n\n

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\u2019s looking forward to more years to come!<\/p>\n\n\n\n

This article is adapted from What I\u2019ve learned about Open Source community over 30 years<\/a> by Jim Hall, and is republished on Both.org by the author.<\/em><\/p>\n","protected":false},"excerpt":{"rendered":"

Open source projects are about more than just the code. It\u2019s about the people that contribute to it.<\/p>\n","protected":false},"author":33,"featured_media":2381,"comment_status":"open","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"_lmt_disableupdate":"","_lmt_disable":"","footnotes":""},"categories":[157,106,158],"tags":[159,316,108],"class_list":["post-7601","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-community","category-history","category-open-source","tag-community","tag-history","tag-open-source"],"modified_by":"David Both","_links":{"self":[{"href":"https:\/\/www.both.org\/index.php?rest_route=\/wp\/v2\/posts\/7601","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.both.org\/index.php?rest_route=\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.both.org\/index.php?rest_route=\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.both.org\/index.php?rest_route=\/wp\/v2\/users\/33"}],"replies":[{"embeddable":true,"href":"https:\/\/www.both.org\/index.php?rest_route=%2Fwp%2Fv2%2Fcomments&post=7601"}],"version-history":[{"count":3,"href":"https:\/\/www.both.org\/index.php?rest_route=\/wp\/v2\/posts\/7601\/revisions"}],"predecessor-version":[{"id":7604,"href":"https:\/\/www.both.org\/index.php?rest_route=\/wp\/v2\/posts\/7601\/revisions\/7604"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/www.both.org\/index.php?rest_route=\/wp\/v2\/media\/2381"}],"wp:attachment":[{"href":"https:\/\/www.both.org\/index.php?rest_route=%2Fwp%2Fv2%2Fmedia&parent=7601"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.both.org\/index.php?rest_route=%2Fwp%2Fv2%2Fcategories&post=7601"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.both.org\/index.php?rest_route=%2Fwp%2Fv2%2Ftags&post=7601"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}