FreeDOS Blog

❮ Back

November, 2009

Open Source and Free Software

About a month ago, I wrote some guest posts for the Collective Imagination blog at ScienceBlogs.* Now that they've run their course over there, I thought I'd re-post them here in case you missed them the first time. Here is part 1 of 4.

The open source software community is fond of using the comparison of cathedrals versus bazaars to demonstrate the differences between how proprietary software ("cathedrals") and open source software ("bazaars") is developed. This model was coined by open source software evangelist Eric S. Raymond in his 1996 essay, The Cathedral and the Bazaar. Raymond's comparison is simple:

Linux overturned much of what I thought I knew. I had been preaching the Unix gospel of small tools, rapid prototyping and evolutionary programming for years. But I also believed there was a certain critical complexity above which a more centralized, a priori approach was required. I believed that the most important software (operating systems and really large tools like the Emacs programming editor) needed to be built like cathedrals, carefully crafted by individual wizards or small bands of mages working in splendid isolation, with no beta to be released before its time.

Linus Torvalds's style of development—release early and often, delegate everything you can, be open to the point of promiscuity—came as a surprise. No quiet, reverent cathedral-building here—rather, the Linux community seemed to resemble a great babbling bazaar of differing agendas and approaches [..] out of which a coherent and stable system could seemingly emerge only by a succession of miracles.
Raymond's is a very concise description of the open source software development model. It also begins to touches on the meritocracy of open source software development, where everyone can contribute, but the best ideas and most talented developers tend to rise to the top. I especially like the cathedral/bazaar comparison because it is:
  1. Simple enough to propagate
  2. Easy enough for non-technical people to understand
  3. Catchy
But what does it mean to talk about "open source software"? This term gets used a lot by the news, by developers, by managers. You see it a lot in places like Slashdot and Scienceblogs. Yet everyone seems to have a slightly different idea of what "open soruce" really means. In some extreme cases, the term "open source" is used interchangeably with "free software". But the two are not always the same.

Open source software

Put in its most basic terms, open source software is any software where the users can see the source code. There are remarkably few rules that govern the conditions under which the users can see the code. However, the Internet community can agree that any software that provides the source code is "open source software".

Unfortunately, this definition is pretty vague. The Open Source Initiative has attempted to document the conditions that define "open source software", as 10 rules:
  1. Free Redistribution
  2. Source Code
  3. Derived Works
  4. Integrity of The Author's Source Code
  5. No Discrimination Against Persons or Groups
  6. No Discrimination Against Fields of Endeavor
  7. Distribution of License
  8. License Must Not Be Specific to a Product
  9. License Must Not Restrict Other Software
  10. License Must Be Technology-Neutral
The gist of these terms is that anyone should be able to view the source code, and that both the program and its source code can be shared with others.

Free software

The Free Software Foundation, led by Richard M. Stallman, takes serious issue with the term "open source":
However, the obvious meaning for the expression "open source software"—and the one most people seem to think it means—is "You can look at the source code." That criterion is much weaker than the free software definition, much weaker also than the official definition of open source. It includes many programs that are neither free nor open source.
Free software is a matter of of the users's freedom to run, copy, distribute, study, change, improve the software. Like open source software, a free software license requires that the source code be made available—otherwise the user would not be able to study, change, improve the program. In this usage, the term "free" refers to freedom, not price. This is also the origin of the meme "Free as in speech, not as in beer."

More precisely, free software refers to the four fundamental kinds of freedoms, according to Stallman:
  1. The freedom to run the program, for any purpose.
  2. The freedom to study how the program works, and change it to make it do what you wish. Access to the source code is a precondition for this.
  3. The freedom to redistribute copies so you can help your neighbor.
  4. The freedom to improve the program, and release your improvements (and modified versions in general) to the public, so that the whole community benefits. Access to the source code is a precondition for this.
The Free Software Foundation guarantees these freedoms through the GNU General Public License ("GNU GPL".) The GNU GPL is designed to make sure you have all the freedoms to use and modify the software as the person who gave it to you, even the author. As an (intended) side effect, source code that is released under the GNU GPL can never become part of proprietary programs, also called "closed source software."

In a Venn Diagram, these are concentric rings. The definition of "free software" lives within the definition of "open source software", which itself sits within the space of all kinds of software. That is, free software is a subset of open source software. So for the rest of this series, let me use the term "open source software" generically.
In my next post, I'll look at open source software using a real-world example. To me, the FreeDOS Project will always be the first example I look to, so I'll use that. It should speak to the commitment of the open source software community that FreeDOS continues under active (if slow) development 15 years after it was conceived. How has FreeDOS held the interest of its users? Because FreeDOS embodies the important qualities that an open source project must possess in order for it to succeed.

Starting Open Source Software

About a month ago, I wrote some guest posts for the Collective Imagination blog at ScienceBlogs.* Now that they've run their course over there, I thought I'd re-post them here in case you missed them the first time. Here is part 2 of 4:

In the first part of this article, I discussed the differences between Free software, and Open source software. In a Venn Diagram, these are concentric rings. The definition of "free software" lives within the definition of "open source software", which itself sits within the space of all kinds of software. That is, free software is a subset of open source software. So for the rest of this post, let me use the term "open source software" generically.

Let's look at open source software using a real-world example. To me, the FreeDOS Project will always be the first example I look to, so I'll use that. It should speak to the commitment of the open source software community that FreeDOS continues under active (if slow) development 15 years after it was conceived. How has FreeDOS held the interest of its users? Because FreeDOS embodies the important qualities that an open source project must possess in order for it to succeed.

But what are the "core" qualities for an open source software project to get off the ground?

Start by solving a problem

In 1994, I was a physics student at the University of Wisconsin-River Falls. I used DOS quite a lot to do data analysis, write papers, dial into the university network, and write small programs to make my life easier. DOS meant a lot to me, and I was very comfortable working with DOS to get my work done.

So it was a big surprise to me when Microsoft announced that they would stop supporting DOS with the next version of Windows, that everyone would soon move to Windows. If you remember the era, this was Microsoft's first acknowledgment of the sea change coming in Windows 95, which certainly was a huge step up for Windows. But at the time, the current version was Windows 3.11, which wasn't exactly user-friendly.

I didn't like Windows. It was klunky, it was slow, it made my work much more difficult. I felt I could accomplish the same tasks in DOS, mostly at the command line, and that I could do it faster than in Windows. In Windows, everything is done by pointing and clicking with a mouse. That just slowed me down, and I felt it was a sloppy user interface to get things done.

I wasn't alone. A lot of other people on various DOS news groups were shocked to hear that DOS would soon go away. They didn't like Windows any more than I did, and were just as resistant to being "forced" into Windows. And many of these people didn't have machines capable of running Windows 3.11, much less a "next generation" version of Windows with all new features. I had an 80386 with 4MB of memory (later upgraded to 8MB.) Many people still ran 80286 machines, and you can't run Windows on that, but DOS runs just fine. If Microsoft were going to push us all to Windows, we'd need to upgrade our PC's, and that didn't seem right. We felt as though our freedoms were being taken away as well, when Microsoft decided to take away MS-DOS.

So I had a problem. How could I continue to use DOS, if Microsoft was abandoning it?

On news groups, people trying to find ways to preserve their freedom. By 1994, Linux had become an underground success story in a lot of universities. I ran Linux on a separate partition on my PC, so I knew it was solid. We looked to Linux and asked, "If they can create a free version of Unix, why couldn't we create our own version of DOS?" Writing a single-tasking DOS system seemed almost trivial next to creating a multi-tasking, multi-user Unix kernel.

So I decided someone needed to write that version of DOS. I looked to the small DOS utilities I'd already written to improve on DOS, and started there. That became my first set of FreeDOS (then, "PD-DOS") utilities: CLS, ECHO, MORE, TYPE, VER, PAUSE. I released them so that other DOS users could use them. Over time, I built them up, added new programs like our first versions of DATE, TIME, CHOICE, DEL, FIND, and Unix equivalents such as TEE and MAN.

The origins of the FreeDOS Project could just as well apply to any other open source software project. In order for the project to exist at all, there must first be a need. A developer solves a problem for himself by writing a program, then shares the program with others so they can use it too. The key is that open source software projects also make the source code available, so that its users can help to add improvements.

Users should be developers

The basic definition of open source software is that the source code must be made available for others to see it. A necessary side-effect of this condition is that anyone who uses the program has an opportunity to make improvements. A well-managed open source software project will accept any improvements in the form of patches, which modifies the program to solve someone else's slightly different (but similar) problem. Releasing new versions of the software with the new features ensures that everyone benefits from these changes.

In the beginning, progress is usually very slow, because you may only have one or two developers making updates to the program. But as new versions are released, others become interested. The program doesn't need to be complete, but it does need to demonstrate that it can do something, that it has the potential to be useful. Then the new users may help add to the code, so the program gets even better. The updated releases generate even more interest, which attracts more users and developers. Repeat as necessary, and even a complex system can become achievable.

Take, for example, the FreeDOS Project's kernel effort. In 1988, Pat Villani started an experiment in writing a bare-bones DOS kernel that could support Pat's embedded device programming. This kernel was Pat's solution to a particular problem, how to re-use code on different platforms without having to re-write very low-level code each time. The DOS kernel changed very slowly over time, because it fit a very narrow set of requirements.

By 1994, Pat realized that others might be able to use the minimal DOS kernel he had written. At the same time, I posted on DOS news groups that I had released the first versions of my basic DOS utilities, and was in search of developers interested in writing a DOS kernel. Pat and I got in touch with each other (via the nice folks at Linux DOSEmu) and Pat's "DOS-C" kernel became the basis of the FreeDOS kernel.

When the source code to DOS-C was made available, the kernel did not support LBA, CD-ROM drivers, or networking. Additionally, floppy disk access was very slow.

But we released this as the FreeDOS kernel anyway. Despite lacking features, despite being slow, we had something that worked. Other developers became interested in what we had produced, and immediately began contributing updates. A developer named "ror4" provided a floppy driver that enabled buffered I/O, dramatically improving performance. James Tabor added networking and support for CD-ROM drives, later improved by Bart Oldeman and Tom Ehlert. Brian Reifsnyder provided LBA support.

As a result of opening the source code to its users, FreeDOS encouraged its users to be co-developers. Compared to Pat originally working on his own, progressing slowly ("cathedral" method) we had a mix of differing developers and approaches that created a coherent and stable system very rapidly ("bazaar" method).

Release early, release often

When many developers are involved in an open source software project project, many patches can be produced in a fairly short time window. It is important to maintain a constant feedback loop to the users, who are also the developers of the program.

As developers submit new patches to a project, it is important to package up the changes in a new release. This can sometimes be a frightening and daunting task, because the original creator of the program may begin to feel that he or she is losing control of the program. Rather, I encourage the viewpoint that the program is "evolving" beyond the goals originally set for it, and it is important to recognize new contributions as good.

The importance of making new releases is that the users/developers will be rewarded with frequent (possibly daily, if the rate of patches supports it) releases with new features. Yet, this can often result in an unstable release, especially at the beginning of a project when not everyone understands the code, and how changing one part can lead to unexpected behavior somewhere else. But over time, most open source software projects stabilize, so that as new versions are released, the program gets better and becomes more stable.

The frequency with which you release new versions will often depend on the size of the project. A small library such as FreeDOS Cats (an implementation of the Unix "catgets" function, which provides support for different spoken languages) might be released quite often. Sometimes, I released more than one version of Cats in a day as users sent me patches, and I released improvements on their fixes. A basic utility such as MORE or TYPE might be modified only in spurts, such as when I added support for Cats, but otherwise remain static. Software with a larger code base, such as the FreeDOS kernel, might take weeks to accumulate enough changes for a new release.

Projects need a coordinator or maintainer

Looking at the relative chaos of open source software development, with new versions released weeks or days apart, you may wonder what holds everything together. How do open source software projects not devolve into self-destruction? Someone needs to coordinate the changes that users contribute to a program. Someone needs to make the new releases. That person is the project maintainer.

An open source software project's maintainer (sometimes called a "coordinator", especially if the program has lots of people contributing to it) should have good communication skills. This person will be responsible for many things, including accepting and merging patches into the program's source code, helping to write documentation, listening to what users are saying about the program and finding ways to accommodate them.

But perhaps the skill that the project's maintainer will find most useful is the ability to listen. The maintainer must recognize that no single person will have all the correct answers all of the time. Insight may come from different directions, and it is the maintainer's responsibility to understand that many people working together on a project ("bazaar") are better than a single individual, no matter how talented ("cathedral").

When I founded the FreeDOS Project, I came into it with the naive view that most of my time would be spent writing code for FreeDOS, and that only a little of my time would be spent doing "housekeeping". My first contribution to FreeDOS was the basic utilities, followed by some kernel updates, the Install program. I thought it would always be like that.

In the early days, this was great. However, as the FreeDOS Project grew, I found my time shifted. I spent less time working on code, and more time answering questions and writing documentation. As more developers joined the project, and the FreeDOS distribution slowly worked its way to "1.0", more than 90% of my time was dedicated to coordinating various efforts across FreeDOS, less than 10% writing code.

After the release of "1.0" in 2006, I became completely hands-off. I no longer submitted patches to programs, I no longer wrote code for my own programs. FreeDOS had grown to the point where I no longer needed to be the expert. Others were pushing FreeDOS to do more things than I had ever dreamed possible in 1994, and I was glad to see it happen.

Each maintainer must similarly find his or her own motivation, and recognize that reasons for staying in a project may change. And that's okay.

In my next post, I'll discuss the organization of an open source software project, and a few of the features a project needs to support itself over the long run.

Cultivating Open Source Software

About a month ago, I wrote some guest posts for the Collective Imagination blog at ScienceBlogs.* Now that they've run their course over there, I thought I'd re-post them here in case you missed them the first time. Here is part 3 of 4:

In the first part of this article, I discussed the differences between Free Software and Open Source Software. In a Venn Diagram, these are concentric rings. The definition of free software lives within the definition of open source software, which itself sits within the space of all kinds of software, so free software is really a subset of open source software. For the rest of this series, I'll use the term "open source software" generically.

Later, I reviewed Open Source Software in the real world, describing the features that an open source software project must have in order to get itself off the ground.

But once an open source software project has gotten started, how does it continue to thrive? How do you build and maintain a community of user-developers who will be interested in adding new features?

Once again, I'd like to use FreeDOS as a case study, since I consider it a very real example of a successful open source software community.

It starts with a web site

When I created the FreeDOS Project in 1994, the Web didn't really exist. It was not until 1995-1996 that the Mosaic browser became readily available, and several years would pass before most users had access to the Internet from their home. So in the beginning, we used an ftp site (hosted by our friends at SunSITE) to distribute all our software and source code. We conversed with one another, and announced new software releases, via USENET news groups.

Compared to today, that's a very limited way to organize a group of developers. In today's world, any open source software project that wants to thrive must provide—at least—a web site for its users. And more importantly, that web site should be well organized.

The project's web site should provide a continuous stream of news items: where is the project going, new developments, major bugs found and fixed, and mention of the project by outside groups. A great way to encourage developers to contribute is to recognize individuals. To an extent, we all like to see our name in print, even in a transient medium like the Web. Spotlight those who make major contributions—but strike a careful balance. One sure way to kill new interest is to present a culture of "us vs. them".

One common mistake is forgetting that an open source software project is for everyone! Too often, new open source software projects dedicate a page to "members" or "developers". As a result, anyone just joining the project gets the impression that the group is closed, too insular. Remain inclusive; it's not a members-only club!

Your web site must make it easy for new users to find a way to contribute. Not everyone who decides to help will be a developer who can write code. Rather, some users will only be able to provide debugging information on odd hardware configurations. Others may have expertise in user interface design, while others may be skilled technical writers. Find a niche for everyone, and advertise on your web site how new contributors can get involved.

Source code

Being open source software means that you need to provide your source code for inspection. This is also the only way for new user-developers to fix bugs and add new features, if they are so interested. So after setting up a web site, your next task should be to open your source code.

How you share the source code may depend on the size of your project. If your program is relatively small, you may only need provide a zip or tar file containing the source code. For example, when I wrote FreeDOS Cats/Kitten (a library that helps a program support multiple languages) I just shared a zip file with all my source code. Cats/Kitten is very small, about 6KB.

If your project is much larger, you may want to look into a source code repository, such as CVS or Subversion, so that users can download just the components that interest them. Today, this is how most open source software projects provide their source code. Look at any project's web site, and you should be able to quickly find a link to their source code repository.

But for your open source software to be successful, you need to provide the full source code every time you make a release. This expectation is built into the GNU General Public License, but it is also a key to building a successful community. Making the source code available to your users allows for the cooperative development and rapid code improvement that fosters "mind share". Not provide the source code—such as making a "testing-only release" or a "preview version"—means your users will not be able to see how your code works. More importantly, your users will not be able to help you fix bugs. Without a way to contribute, developers tend to lose interest in a project, and find something else to do.


Most users often experience a new open source software project through its documentation. Before going through the trouble of downloading new code and testing it out, people want to get acquainted with how the software is supposed to work, and decide if it is right for them. So it is not surprising that many successful open source software projects often put a large effort into making the documentation a first-rate experience.

Writing good documentation is hard, though. Developers who are very technically minded often are not able to write instruction manuals that are easy to understand. So how do projects produce useful and meaningful documentation?

This is such an important step for many projects that some projects split off a separate, related project just to update the documentation. For example, Linux enthusiast Matt Welsh co-founded an effort to provide documentation for fellow Linux users, by writing recipe guides called HOWTOs. Today, Matt's project lives on as the Linux Documentation Project (LDP) and their HOWTOs receive the same level of praise as any O'Reilly book. In fact, O'Reilly has published several LDP HOWTOs as books.

Recognizing the success of the LDP had in helping users understand Linux, I created a similar documentation effort for FreeDOS. In founding the Linux Documentation Project (FD-DOC) we followed the spirit of Matt's intent with the LDP. It would be well for any similar documentation effort to follow the same goals:

The documentation project is primarily a vehicle for enthusiasts and developers to share their knowledge about the system with other users and co-developers. People are motivated to contribute to the documentation effort because they know it helps many people.

The documentation project, if you have one, should be the de facto place for people to visit to find out about your open source software project.

As such, it is vital that it is as easy as possible for new authors to contribute to the documentation effort. If you institute complex document standards, create voting organizations, or require participation in mailing lists, you will discourage many potential new contributors from helping you.

Likewise, the tools to create documentation should be easy to use, widely-available, free, and well-supported. When we started the FD-DOC, we adopted roff (ms) to typeset our documents. We found it was widely-accepted, and many people already knew how to write with it. Those who were unfamiliar with roff typically had a short learning curve. However, times have changed. I recommend modern open source software projects create a wiki where users can become editors.

It is important to remember that the documentation project should be open for contribution by anyone, and is not a closed, private club. Otherwise, the documentation project will not be interesting to any but the few people who created it in the first place.

Bug tracking

Often a major sticking point for newcomers to open source software is the issue of tracking bugs. To empower your users to be co-developers or user-developers, you must provide them the tools they need to be efficient contributors. A successful open source software project must equip its developers with a bug tracking system. After all, a software project cannot improve itself if it cannot identify what it wrong in the software.

When I think about bug tracking, I am reminded of this quote:

The highest sounds are the hardest to hear. Going forward is a way to retreat. Greater talent shows itself late in life. Even a perfect program still has bugs.
~Geoffrey James,
The Tao of Programming
There are a number of different bug tracking systems that you can take advantage of. Bugzilla seems to be the most popular these days, but I have also used GNATS and Jitterbug with some success. These bug tracking tools all share a common set of features that you should look for in your open source software project:
  1. The bug tracking system must be easy to use: entering new bugs, and following existing bugs. If your system is too difficult to use, no one will want to enter new bugs, and problems in your software will remain unfixed.
  2. The bug tracking system must have a strong query capability. If your users and developers cannot look up existing bugs, you'll find your project will get flooded with lots of duplicate bugs.
The system must be open to all eyes. This is perhaps the most important—and yet most difficult—feature for traditional software managers to understand. In the cathedral model of software development, bug lists are often hidden from customers. After all, there is no beta released before its time, so why would you advertise features that are broken until you have had time to fix them? However, in the bazaar model of open source software, everyone who uses the software is potentially a new developer for it. In order to foster new fixes and patches to the system, developers must be able to see what work needs to be done, and what features need to be addressed.

Respond to submissions

Treating your users as co-developers is your least-hassle route to rapid code improvement and effective debugging. Because the source code is available, anyone can contribute patches and new features. Given a bit of encouragement, your users will diagnose problems for you, suggest fixes, and even send you source code that helps to improve your project far more quickly than you could on your own.

However, the only way to keep your users working with you as co-developers is to respond to the patches and suggestions they send you. Your best bet to keeping your community engaged and stimulated is the sight of constant improvement in the system they are using.

In the FreeDOS Project, I wrote a lot of utilities and other programs. My most active development efforts were aimed at our first Install program, and later the Cats/Kitten library. Looking at the Install program, early in the development cycle, a very talented developer named Jeremy Davis found an interest in how the Install program worked, found some bugs, and submitted a few fixes to me. Eager to have help in my coding, I responded immediately by reviewing his patches and checking them into the source code tree, and releasing a new version. Releases of the Install program became more frequent as bugs were quickly identified and patches.

Similarly, when I first wrote the Cats library, it was a small effort to recreate the Unix catgets functionality. But since many people around the world contribute to FreeDOS, my Cats library became popular very quickly. I received patches from different developers, adding features, improving Unix compatibility, and reducing the memory footprint. Releases happened very quickly, sometimes several versions in a single day if we had enough of us collaborating. Eventually, we had introduced so many new features yet in a smaller size, I renamed the library to Cats/Kitten.

None of this would have been possible had I stopped responding to the users who were acting as my co-developers. The key was constant feedback.

The worst thing that can happen to an open source software project is to become unresponsive to its users. A sure way for a project maintainer to kill interest is to reply to developers with "Thanks for the patch, but I was planning to add that anyway in the next release."

It's not pixie dust

Finally, let me remind anyone interested in starting an open source software project that open source software does not imply automatic success. Just because you release your project as "open source software" does not mean you will develop a community to help you, even if you do everything "right". No project, either open source or proprietary, can guarantee that it will survive the test of time.

Jamie Zawinski, a well-known open source software developer, wrote of his time with Netscape as it became "open sourced” as Mozilla:
Open source does work, but it is most definitely not a panacea. If there's a cautionary tale here, it is that you can't take a dying project, sprinkle it with the magic pixie dust of "open source," and have everything magically work out. Software is hard. The issues aren't that simple.
In other words, open source is not a magic bullet. A project must be interesting to other developers in order for them to contribute to it. Realize that your software just may not be that cool to many other people.

An example is a project someone once wrote for FreeDOS. The FreeDOS Internet Services Host (FISH) was written in 1999 by Gregory Ball, as a web server that ran on a PC running FreeDOS. Really, the program was a demonstrate that network applications could be written for FreeDOS using WATTCP, the standard library for TCP/IP in DOS. Gregory deployed FISH on an 80386 SX/25 computer with 4MB of memory, but his web site advertised it would run on a lesser system.

This was a really cool project, and I admired it for its unadulterated hack value. However, no one really believed that people would run serious web servers on a DOS-based system. Apache was a much more common system that supported more features. So FISH sort of fell by the wayside, and failed to generate enough interest to maintain a community. Eventually, the last FISH server was turned off, and no one noticed. Being cool just wasn't enough if people weren't interested in using it.
In part 4, I'll talk about the final stages in an open source software project, and how to maintain an effective transition of the maintainer role.

Transitions in Open Source Software

About a month ago, I wrote some guest posts for the Collective Imagination blog at ScienceBlogs.* Now that they've run their course over there, I thought I'd re-post them here in case you missed them the first time. Here is part 4 of 4:

In 1994, I created a free version of DOS, a system compatible with MS-DOS but open for others to use and improve. This became the FreeDOS Project. Since then, I have been tightly integrated as the project's primary coordinator and maintainer.

Yet in February 2009, I decided to leave FreeDOS. This was not an easy decision. After 15 years, FreeDOS was a large part of my life, and I had invested a lot of my time and energy to the project. However, I had applied for a Master's degree program, and realized my studies on top of home life and work commitments would leave little (or no) time for FreeDOS.

In part 3 of this series, I discussed how the maintainer can help a project thrive. The maintainer plays an important role in an open source software project. For the FreeDOS Project to to survive, I needed to transfer my role to someone else.

So the question is, How to transition these responsibilities to someone else?

Communication is key

Transition is really about change. The first step in making a change is communication. So on February 8 2009, I emailed the FreeDOS mailing list with a note that I would be leaving the project:

Just wanted to let everyone know that I've decided to pursue a Master's degree (M.S.—MOT). This will require a considerable time commitment from me, for the next two years. In order to concentrate on the course, I'll need to take a leave of absence from the FreeDOS Project starting in May.

I know FreeDOS will be fine during my absence. We have the FreeDOS Wiki to help manage our user-contributed documentation. Bug tracking has moved from bugzilla to the SF Bug Tracker. I'm not the only person with access to the FreeDOS files archive at ibiblio, nor the only person who can edit the web site.

I'm sure others will be able to fill in for me while I'm gone, so my absence isn't really that critical.
This was my first communication regarding the transition. It's not a coincidence that the email clearly reminded people that others already held the same roles as myself (files archive, web site). This was an important message. If the community stepped up, my exit would not be disruptive for FreeDOS.

In fact, the response to my message was relative calm. Many wrote to express their thanks for having built up the FreeDOS Project, others emailed with general support and encouragement. But no one complained that FreeDOS would "die"—people realized I wasn't irreplaceable, and we would make the transition in time. After all, I made my announcement more than 3 months in advance of my departure.

Understand the roles

It seems a basic concept, but worth saying anyway—in order to transfer responsibilities to someone else, everything needed to be documented. A few days after announcing my exit, I began writing down everything I worked on: web site, files archive, mailing list, project admin, etc. From there, I documented my tasks within each role, and (where possible) included a history so the next guy would have some context.

The FreeDOS Project has a wiki, so I captured everything there, adding links to other sections. The next few weeks were a flurry of writing how-to notes and chronicling the history of various minutia.

Just do it

After a few weeks, several people volunteered for various administrative duties on the FreeDOS Project. My documentation removed the mystery from the daily tasks kept FreeDOS running smoothly.

For example, Rugxulo offered to be a news editor, posting announcements about new development in FreeDOS programs. When Rugxulo made his first news post on February 26, I backed off and let him take it for his own.

I realized the hardest step wasn't writing that email in February. It was when I made my first hand-off to someone else on the web site. A handoff isn't real unless the first person stops doing it. So while I wanted to keep posting news, it was important for me not to, to let the next person take it from there.

Even more difficult was not meddling. People learn best when they can discover things on their own. For exampel, Rugxulo's first few posts were not written in the style I would have used – but this was his responsibility now, and he needed to figure out his personal style on his own.

From my experience, this is the hardest thing for any long-time project maintainer to do during a transition. Announcing your departure is one thing; doing it is something else. That takes strength of will.

Let it go

During the next few months, I was pleased to see so many people from the FreeDOS community come together in support of the transition. The news handoff went well, so people volunteered to take on other roles. Pat Villani (author of the FreeDOS Kernel) returned to become the new coordinator of the project. By May, I was acting solely as an adviser.

But at some point, you need to really let it go. So, difficult as it was, I wrote a final note to the FreeDOS mailing lists to announce that the transition was complete:
Back in February, I had announced that I was taking an absence from the FreeDOS Project to focus on an MOT program, effective in May. I've been transferring my roles in FreeDOS (webmaster, SourceForge admin, ibiblio admin, etc.)

May is finally here. I'm going to unsubscribe from the mailing lists, and officially take my leave from FreeDOS. It's been a long transition, but I think it's been a smooth one. With the support structure we have in place now, I think FreeDOS will do just fine without me running things. For example, Rugxulo has been regularly posting news updates to the web site, and others have been updating ibiblio.

Any emails that are sent directly to me will be forwarded to one of the other admins. I'll probably still post items to my FreeDOS blog but I'm now out of the day-to-day running of the FreeDOS Project.

I've worked on FreeDOS since that day in 1994 when I posted a note to the comp.os.msdos.apps newsgroup to announce a new, free version of DOS. Since that time, we've seen FreeDOS "grow up", marking our official "1.0" release in 2006. Today, FreeDOS is used all around the world, in a variety of industries. Embedded systems have found FreeDOS to be useful, and classic gamers are able to run their old DOS games on PC hardware. I look forward to what FreeDOS 1.1 (and an eventual FreeDOS 2.0) will bring.

It's been great. Thanks to everyone!
And that was it. I missed being involved in the project, but I wasn't concerned about its future; I had handed over the keys to others, and built up an active community of user-developers.

The final responsibility of an open source software maintainer is to hand off the project to someone else. It's a hard step, that final transition. But it's important for the project to survive on its own. And more importantly, it's possible.