Thursday, December 31, 2009

New web design

The New Year brings an opportunity for change. So to celebrate the end of 2009, and the beginning of 2010, I have posted the new web design for the FreeDOS web site. Thanks to nodethirtythree for this great update!

Note that if you are using a mobile device, you will [automatically] get a slightly different version of the new web design, optimized for mobile web browsers with limited resolution.

Monday, December 28, 2009

This is awesome

I wanted to share this with you: my friend Joel Watson of Hijinks Ensue is trying to make the webcomic his full-time job. As part of this experiment, he sold "artist editions" of his first book (a collection of all his comics from 2007-2008.) If you buy the premium "artist edition", Joel will draw a sketch for you in the book (thus, ruining it.) :-)

I figured the "artist edition" was a great way to support a webcomic I enjoy. I asked for a version of Blinky, drawn in the style of "Joel" from the comic, including the beard and hair. I think it looks great:

Let me zoom in and add some color:

This is awesome. Thanks, Joel!

Tuesday, December 22, 2009

Web design update

About 2 months ago, I posted a note asking for help with the FreeDOS web design. The stylesheet is okay, but could use some updating. Specifically, the orange bar at the top of the page was meant to harmonize with SourceForge's colors, back when their colors were silver and orange. But they changed their colors to blue now, so the an orange bar makes no sense.

I figured, if I was going to update the FreeDOS web design to match the colors, it would be time to tackle a few other things that need improving. But I'm just not a web designer. So I put out a call for web designers to help us.

I didn't get much in response. In fact, only 2 people sent back a design concept.

One user (who didn't provide a name) sent me only an image of his idea for our new look:

Another user (Bonnie) suggested a background image for the site, but did not provide a full design. It would have looked like this:

Unfortunately, neither provided a stylesheet, and I haven't been able to get back in touch with them since then.

Instead, I contacted AJ at nodethirtythree design. He agreed to help me, and modified one of his existing web designs ("nonzero_blue") for use on the FreeDOS web site. I think it looks great! I'll put the new design up in a few days.

Sunday, December 20, 2009

Velvet Christmas

This year, I had a great idea for a Christmas gift to give one of my friends. It was an idea so awesome, so massive, so merciless, that it required the help of many other friends to make it happen.

One of my friends is Kelly McCullough, who you may know as the author of the WebMage series. He has 4 books out now, with a 5th on the way. Kelly has been very lucky to have been paired with a terrific artist who created wonderful cover art.

I thought "what better gift for Kelly than to give him a larger version of his cover art?" Something he could hang on his wall. And so the idea was born. I immediately contacted a bunch of our other friends, to get them in on the plan.

The first book will always be close to Kelly's heart, so we picked that one. The art piece had to be special, not just a larger-scale reproduction of excellent cover art. There could only be one way to do this: it had to be a velvet painting. With the assistance of Bill Robison, I commissioned a velvet painting for Kelly.

We presented Kelly with that painting last night:

The reaction was priceless, all we hoped for:

I'd like to thank my fellow conspirators in the plan:

  • Laura
  • Sara
  • Ben & Steph
  • Nancy & Bill
  • Shari & Steve
  • Sean & Kat
  • Ben R
  • Rebecca

More pictures are available at Wyrdsmiths. Kelly lays at least part of the blame on John Scalzi, which is fair to do, as that is where I got the idea.

Tuesday, December 15, 2009

When Technology Fails

A friend reminded me the other day that I should post something about how I was interviewed for public television last year. [In the U.S., we have regular commercial television, but also "public television" that is supported in part by direct contributions by viewers.]

Unfortunately, I wasn't interviewed about FreeDOS. Instead, I was asked to be a guest expert on technology. Specifically, the show topic was "When Technology Fails" and discussed what happens when IT doesn't work the way it's supposed to, and how you can prepare yourself with backups and such.

So, if you've ever wanted to see me in person, go watch the episode. I was the second of 2 guests, so I appear at about 15 minutes into the show.

Wednesday, November 18, 2009

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.

Monday, November 9, 2009

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.

Wednesday, November 4, 2009

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.

Monday, November 2, 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.

Friday, October 23, 2009

Cultivating Open Source Software

Part 3 of my guest post series is now up at Collective Imagination. In this post, I discuss the features an open source software project needs to thrive - using FreeDOS as an example. Please leave a comment!

Tuesday, October 20, 2009

Are you a web developer?

The FreeDOS web site has always been run by volunteers. M. "hannibal" Toal was our first webmaster, but after he left, I took on the web site duties. I mostly picked up design elements from my favorite web sites, eventually settling down to the "blue" web site we have now. It was a slow evolution, to be sure, since I am definitely not artistically inclined.

The new default stylesheet now uses an orange bar at the top for all our links to hosted apps at SourceForge. (SF used orange as their primary color, so it was less shocking to click on those links and then be presented with an orange-and-silver SF page.)

Since then, SourceForge has changed their colors, now using blue-and-grey. So I thought it might be a good time to update the FreeDOS web site, at least so the "SF" bar color is a closer match to SF's colors.

It occurred to me that if I changed that, I really should clean up the rest of the FreeDOS web design at the same time. But I'm just not a web designer, so I need help. I think it would be better to find a [semi-] professional web designer to update the FreeDOS web site stylesheet for us.

If you have a talent for web site design, or know someone who does, this is for you: Help us update the FreeDOS web site.

There are a few "rules" in finding a new FreeDOS web design:

  1. You must use the FreeDOS fish logo. However, feel free to create a new "FreeDOS" banner that uses the "Blinky the fish" logo. I prefer the original color, not the purple we use in the "glossy" fish.
  2. Our primary colors are blue. I'm not stuck on the particular shade we use now, just as long as it looks good with the FreeDOS fish.
  3. We must use the SourceForge logo. This is a requirement from SourceForge, since we are hosted by them (but you can choose other SourceForge logos that may better match your colors.)
  4. I'd prefer to keep the amount of web site edits to a minimum when implementing a new design; if you can, use the existing xhtml document structure. However, I'm open to moving content around, or editing the banner/footer, or moving some content to sub-pages. For example, maybe the Software page should be split into two pages, so the LSM stuff is on another page (or in the wiki)?
  5. The front page is tricky, since this needs to have information for new users, and news updates for current developers. We also have an "announcements" box, which may not always be shown. Other pages will probably be easier.

I'm not particularly fond of the fonts that we use on the site. Feel free to change them.

Interested? Web designers can submit their design idea via email (you can send them to the mailing lists for discussion if you want - but send your final version to me.) I prefer to get a link to your own web site, showing the design idea. I'll post the top finalists in about a month, and provide a way for people to vote for their favorite new web design. I'll pick the winner based on the votes.

Don't have a web site? Note that almost all pages on the FreeDOS web site recognize the "css=" directive, so you can specify your own stylesheet. For example:

What does the winner get? As a kind of "reward" to the winner, we can provide a "Original site design by __" link in the footer. This might be a resume-builder for someone trying to break into web design as a profession, or another reference for someone who is already a professional web designer.

Wednesday, October 14, 2009

Open source software in the real world

Part 2 of my series of guest posts has been posted at Collective Imagination: Open source software in the real world. It uses FreeDOS to demonstrate the critical components an open source software project needs in order to get off the ground. In part 3 (this weekend) look for the core features a project needs to sustain itself.

Friday, October 9, 2009

30 years of VisiCalc

Dan Bricklin and Bob Frankston released a small program in 1979 for the Apple ][ computer that changed history. VisiCalc was the first spreadsheet program, and turned the personal computer into a serious business tool.

This month (October) marks the 30th anniversary of VisiCalc. While the DOS version of VisiCalc wasn't released until 2 years later, I thought it important to take a moment to celebrate this important milestone in PC history.

For those of you that are not familiar with VisiCalc, you are probably working with Microsoft Excel or other spreadsheet applications. Under FreeDOS, you may have used AsEasyAs—which is still available. These spreadsheets still market themselves around some of the basic features first introduced in VisiCalc.

For those of you that are familiar with VisiCalc, take a moment to think back to what it allowed us to do. You can romanticize the memories—remember the good, gloss over the frustration. Please post your thoughts in the comments, below.

On Free/open source software

Just thought I'd let you know I've written a guest post at Collective Imagination on Free/open source software. This is intended to be the first of (probably) 3 guest posts on Free/open source software. The next post will begin discussing the qualities that an open source project must possess in order for it to succeed.

I'll probably republish the articles here after they've had their run on Collective Imagination.

Sunday, July 26, 2009

FreeDOS on Twitter

As many of you are aware, you can now follow FreeDOS on Twitter: @FreeDOS_Project. Thanks to Pat Villani for setting this up for us!

However, note that there is a squatter on the @freedos name. That person seems to be just using the name, and hasn't posted any tweets. We're trying to get this resolved. In the meantime, if you want to follow FreeDOS on Twitter, make sure to use @FreeDOS_Project.

BTW, it's unfortunate to request that Twitter remove this squatter. If the person had been using the "freedos" account for something, even related to FreeDOS, that probably would have been okay. Not to mention, I'd really like to see the FreeDOS Project use @freedos for our Twitter feed, and it's clear this guy is just squatting on the name.

Monday, June 29, 2009

Birthday wrap-up

I thought it would be neat to post a followup to the FreeDOS turns 15 years old item. Several tech news sites ran the story:

And it was great to see friends and associates with their own blog posts about FreeDOS's "birthday":

Here's looking forward to a great future with FreeDOS! I think DOS will be around for quite some time yet. I'm especially interested to see what a future FreeDOS 1.1 and 2.0 will look like, what changes we can bring to FreeDOS, and still retain what makes it "DOS".

Sunday, June 28, 2009

FreeDOS turns 15 years old

Man, it's been a long ride, but a great one. FreeDOS turns 15 years old today! A little bit of history:

"PD-DOS" was announced to the world on June 28, 1994. To cement my ideas, I created a PD-DOS Manifesto, which you can read elsewhere on the web site. The idea of a "free DOS" immediately became popular. Within a few weeks, several coders contacted me, wanting to take on this or that part of the new DOS.

Weeks after that, the number had doubled. I was contacted by Pat Villani, who had already written a functional DOS kernel called DOS/NT, and who was willing to release it under the GNU GPL for us to use! Tim Norman also started work on his version of, which is the heart of the DOS command line interface. I think the fact that, early on, we had access to a working DOS kernel and really helped get the project in motion.

By July 24, 1994, the name of the project had officially changed to "Free-DOS", to reflect the fact that we were Free Software, not really "public domain." Later, we dropped the dash entirely, and became "FreeDOS".

DOS will be around for quite some time yet. DOS remains a great environment to work in if you are building an embedded system, for example. The operating system is light, so it will run well in a device that doesn't have a lot of memory. I like to use FreeDOS to run the old classic DOS games that I loved.

Saturday, June 20, 2009

Mark your calendars

FreeDOS turns 15 years old next week. Mark your calendars now!

For me, this is all about remembering how things started. When I was still a physics student at university, I saw a mention on a DOS user group that Microsoft would stop support for DOS, that a new version of Windows would permanently remove DOS from the picture. (Later, we learned Windows 95 still used quite a bit of DOS, but at that time we all had the vision that Microsoft was trying to kill our favorite operating system.) Everyone was pretty shocked. We didn't want to be forced to use Windows, which completely removes the command line. In DOS, everything is done on the command line, and a true command line "guru" can do amazing things there. In Windows, you are stuck with the mouse, and if the menus don't let you do something, it pretty much can't be done. So things were looking pretty bleak. We were all very upset about Microsoft's decision to ditch the DOS platform.

Then, I saw a discussion thread on the DOS groups asking "hey, why doesn't someone write their own free version of DOS?" Remember, this was about three years after Linus Torvalds announced his work on the Linux kernel, and by 1993 Linux had shown that free software can achieve incredible results. So in 1994, the suggestion that we could write our own free version of DOS, and give it away with the source code so others could work with it and improve it, really didn't sound all that far-fetched.

So I decided to give it a go. After I'd written over a dozen utilities that replaced MS-DOS commands, and found some public domain source that implemented other functionality, I realized that you could reproduce what MS-DOS does and make it a free software project. I released what I had for others to try, and the FreeDOS Project pretty much picked up from there.

What are your favorite memories of FreeDOS?

Tuesday, May 26, 2009

Attending WisCon

Just got back from attending WisCon. This was my second year attending the con, and I'm planning to return next year. If you're also going to be there, look me up!

For next year, I'm thinking about putting together a panel to discuss open source software projects, and equality. It's unfortunate in industry (even in higher ed, where I work) that the I.T. field is mostly men. That is slowly changing over time, and it's better now than 5 years ago. Compare this to working in the open source software world - where your technical proficiency stands by itself.

I think a panel could generate very interesting and insightful discussion. If you're planning to attend WisCon 2010, and would be interested in participating in this panel, email me soon!

Monday, May 11, 2009

Welcome back, Pat

Most of you should recognize Pat Villani. He is the original author of the FreeDOS kernel, and has been with the FreeDOS Project (off and on) from the beginning.

Pat contacted me about taking on the role of FreeDOS project coordinator. Pat & I really had been discussing this for weeks, but we decided not to announce anything until he & I could talk in person. (It just took a while to get a phone call scheduled, since I was so busy until Penguicon.) Since we no longer have a single person who fills this particular role, I agreed that Pat would be an excellent person to step in now that I am absent from FreeDOS. Welcome back, Pat Villani!

Sunday, May 10, 2009

Moving on

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 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!

Monday, May 4, 2009

Penguicon wrap-up

I got back from Penguicon 7.0 last night. I had a great time! Alas, Wil Wheaton was not in attendance, due to illness. I wish him the best. And the CandyFab broke down before they could do any demos, which was disappointing.

As a Nifty Guest, I gave a total of 3 presentations at Penguicon:

Each talk was well-attended. If you'd like to see the slides, click the links above. I'll warn you now, though: many of the slides are very "conceptual", so you may not be able to make sense of them without hearing me talk about them.

Wednesday, April 22, 2009

Inside the box

Sometimes, thinking "outside the box" means working inside a box. Or a container, like a virtual machine.

In an email with someone (I think it was Rugxulo) I proposed an interesting new path for FreeDOS:

Create a very lightweight Linux system that boots, run DOSEmu on virtual console #1, which immediately boots. The other virtual consoles provide an ability to run DOSEmu, which also can boot FreeDOS.

There should be a simple method to direct the Linux host system to "shutdown" or "reboot" from within the DOSEmu - but it could be as simple as: when DOSEmu exits on virtual console #1, present a quick menu to do a "soft reboot" (restart DOSEmu) or "hard reboot" or "shutdown" (both affect the Linux host system.)

In this way, a certain level of abstraction or virtualization is realized. You can run separate instances of FreeDOS in the different virtual consoles, providing a kind of "DOS multitasking" (but really, it's just instances.) An interesting step forward (and not too different from what some virtualization companies are proposing) but it's missing the things necessary to bring DOS to the next level. (See my other posts.)

Still, it's an interesting idea, and I'd be very curious if anyone ever created such a thing. Any takers?

Sunday, April 19, 2009

Modern DOS

What would it take to create a "modern" DOS? I can think of a few things:

We need to have native USB support, rather than relying on "legacy mode" to access keyboards, mice, and USB storage. FreeDOS should recognize USB storage devices as they are connected, and disassociate them when they are unplugged. This will require massive changes to the DOS hard drive/floppy drive infrastructure, as I could connect one USB fob drive to my system as easily as I can connect 6 or 7 fob drives. FreeDOS should have a way to access them all. As I mentioned in anohter post: drive letters are probably a necessary evil. But imagine a method that maps a USB fob drive to an easily-located path on C:

A GUI is also necessary to take FreeDOS to the next level. That GUI needs to be a stable system with an API support that makes it easy to write new applications. We never picked an official GUI - but OpenGEM is a possibility, and it's very solid. But the user interface could be prettier. I don't necessary mean eye candy, but two changes will dramatically improve the look: support for loading TTF fonts, especially if the user can select one of those fonts as the "system" font, and an updated icon theme. User-loadable themes (ala GNOME and KDE) aren't necessary—but simple, outlined multi-color icons would improve GEM usability dramatically.

Of these, the GUI is easiest to tackle. I'd encourage anyone who wants to contribute to FreeDOS to consider helping OpenGEM.

Wednesday, April 15, 2009

Networks and FreeDOS

I'd like to take a moment to look at the state of FreeDOS support, and what would help move FreeDOS to the next level.

DOS needs drivers, plain and simple. Video cards are one thing, but simple VESA support can go a long way to support video on DOS. The urgent need is with networking: when DOS was first created, no one ran PCs on networks. So DOS wasn't built with network support. Since then, TCP/IP is the way, and wireless networks are very common. FreeDOS needs to build a library of network card drivers, supporting both wired and wireless networking over TCP/IP.

The network stack in FreeDOS needs to be simplified. Old applications needed to have the TCP/IP stack linked in (WATTCP, for example.) Imagine a new FreeDOS that provided its own TCP/IP stack, so that applications could make an API call to access network resources. Legacy applications would need to be supported here, but new "FreeDOS 2.0" applications would be able to take advantage of the new framework.

A web browser is essential here. The Arachne browser is very limited, and needs a complete overhaul. I wrote a comment on the mailing list earlier today about Arachne - my #1 wish is that it supports stylesheets.

Mapping drive letters to access the LAN should be a thing of the past. I'd like to see a mapping system that connects a network resource (say, a CIFS share) to a path, similar to "mount" on UNIX. While drive letters are a simple mapping (and probably a necessary evil, given the amount of DOS software that already exists and assumes drive letters) imagine a system where C:\NETWORK\CIFS\HOME maps a CIFS connection to a remote server on the network (the name HOME is merely a label, chosen when I "mount" it.) Note that old DOS applications would still work under this model, as there is a recognizable drive letter and path to the resource - but the resource happens to be on a server on the network.

As you work on the future of FreeDOS, what things would you change?

Friday, April 10, 2009

Multitasking in DOS?

People sometimes ask me what I'd love to see in a future version of DOS. I would like to see some level of running multiple applications at once. The difficulty will be maintaining compatibility with older DOS applications; DOS was not originally designed to support more than one active application (excluding TSRs.)

True multitasking would be ideal, but I'd be happy if we supported the simpler "task switching" - this would be a huge leap forward for FreeDOS. MS-DOS5's DOSSHELL supported hotkey "task switching" and a welcome addition. But we need this at the kernel level to be really powerful.

But so far, I've only mentioned incremental changes to the FreeDOS paradigm. Let's think transformatively: throw off the chains of 8088 backwards compatibility, and look to the modern systems!

What would you change in a "next generation" version of FreeDOS to make it stand out?

Monday, April 6, 2009

New ibiblio maintainer

As I plan my transition in May, I also need to remember to pass on my role as 1/3 FreeDOS ibiblio maintainer. (The other maintainers are Aitor and Blair.) It's worked well to have 3 of us maintaining the FreeDOS files archive at ibiblio. With 3 maintainers, it's very unlikely that the FreeDOS Project will completely lose the account info if one of us suddenly becomes unavailable.

Anyway, around May 4 I'll make Mateusz Viste an ibiblio maintainer, so he can upload FDUPDATE files there. I'll stop doing any ibiblio stuff after that date.
Update: (Apr 9 2009) I've been thinking about this, and it's silly to wait until May for me to transition my role of 1/3 FreeDOS ibiblio maintainer to Mateusz. We should do it now, so that if anyone has questions about our file archives at ibiblio, I'm still around to ask. I've just shared the login info with Mateusz. I'll stop doing any file maintainer stuff on ibiblio after today - Aitor, Blair, and Mateusz are now the official FreeDOS ibiblio maintainers.

Saturday, April 4, 2009

New webmasters

I have now removed myself from the Webmasters page. Technically, I'm still a webmaster, and I may even update a few web pages occasionally, but new contacts should go to Aitor and Eric. Obviously, I'm still around until sometime in May, so you can feel free to email me with questions, etc.

Tuesday, March 31, 2009

Moving forward

At the end of my involvement in FreeDOS, I ask myself: What does FreeDOS need to move forward? What should FreeDOS do to make it stand out?

First, I think the FreeDOS kernel needs to be cleaned up. There has been a lot of tinkering in the kernel, trying to save 10 bytes here, 8 bytes there, 12 bytes somewhere else. While the motive was good (kernel should take up the least memory possible) what's happened is that the kernel source code became more difficult to work with. DOS should be a fairly simple thing, compared to other kernels. I want to encourage some interested developer to pick up the source code and simplify it, even if that means undoing any of the memory savings.

Above all, the kernel needs to work reliably. Today, we have two branches of the FreeDOS kernel: 2036 stable, and 2037 devel (unstable). That shouldn't be ok, yet somehow we've convinced ourselves this is acceptable. Having two versions of the kernel, where the most recent branch is effectively "broken", is what's keeping us from moving forward with the kernel. Is it easier for a kernel developer to start with 2036 and re-add the features from 2037? Or is it better to fix the broken parts from 2037, to release a (working) 2038 version? I lack the skill to do any kernel development, so I never tried. I'm hoping someone with the necessary energy and enthusiasm can work it out.

Thursday, March 19, 2009

Next steps in transition

I have been thinking about the next steps in the transition, so that there's a seamless transfer when I step away from the FreeDOS Project in May. Obviously, I'm still around at this point, so you can feel free to email me with questions,etc. But starting in April, anyone who tries to contact a webmaster really should get pointed to Aitor and Eric. Just to let everyone know, around April 4 I'll remove myself from the Webmasters page. I'll still be a webmaster, and I may even update pages after that time, but new contacts should go to Aitor and Eric.

I'm not sure what mail lists I'm still subscribed to, but I'm also considering taking myself off all lists except freedos-devel as of April 4.

I plan to continue updating the FreeDOS Wiki, and posting "vision" items to my blog page. However, I will try to avoid posting any news items on so others can get some practice doing that.

Thursday, March 12, 2009

Using the wiki

I had an email discussion with someone about the FreeDOS Wiki, asking about the "help" pages that show the usage of the different FreeDOS commands. For example, the page for As I mentioned in my other email, the in the wiki was split off from the Spec. It is a reference standard only, not necessarily the command line options that can be used with the actual FreeCOM/

I split off each of the commands from the FreeDOS Spec because too many people assumed the Spec was a single "cheat sheet" that showed how to use each of the commands. And of course, that's not true; the Spec is only a reference standard, what commands must support. Which is why the entry has a simple usage.

But by splitting off each of the commands into its own page, I have set it up so that someone (Fritz? Eric?) can go into the wiki and update the command line data with the actual command line usage. That would make the wiki the obvious place for everyone to get help info, and for the Fasthelp program to pull its documentation (for example, a developer with a Linux desktop could easily script a method to pull all the wiki pages for all the FreeDOS commands, and save them as individual html pages.) The wiki conveniently puts all the content for this in <div id="content"> so would be easy to script. I did something very similar for my blog, but the div name was different (obviously.) Here's my blog example. Behold the power of AWK!

/<div class="post hentry category-/ { blog=1 } /<div/ { if (blog==1) {div++} } { if ( (blog==1) && (div>0) ) {print} } /<\/div/ { if (blog==1) { if (--div == 0) {blog=0} } }

I haven't tested it, but I think if you changed the first line to use <div id="content"> everything would work automatically.

It would be better to maintain some pointer back to the reference version, but I have to leave that to someone else since I am leaving the project in May.

University of Minnesota

If you live in Minnesota, especially in/near Minneapolis, you may be interested to know that I'll be speaking at the University of Minnesota. I don't have an exact date yet, but it will be mid-April. My talk will be about Free software development, using FreeDOS as an example. I'm looking forwards to it!

Saturday, March 7, 2009

Attending Penguicon

I have been confirmed as a Nifty Guest for Penguicon 7.0, a science fiction and open source software convention. This year's Penguicon will be May 1-3, at the Crowne Plaza Hotel in Romulus, Michigan. I'm presenting at two sessions: "Linux in the Enterprise" and "Starting your own Free/open source software project." Other guests planning to attend include Wil Wheaton, and John "maddog" Hall (no relation.) It should be a lot of fun!

If you're planning to attend Penguicon, look me up. I'd love to see lots of FreeDOS friends in the audience!

Saturday, February 28, 2009


Rugxulo recently posted a news item about compiling UPX-UCL. For those who don't know: UPX is a n executable compressor for multiple platforms, supporting tons of formats. UPX even allows commercial use of stubs. UPX's default builds use NRV or LZMA for compressing, but the sources include UCL (compatible with NRV with only slightly less efficient compression). Rugxulo wrote that he compiled UPX-UCL with DJGPP 2.04 / G++ 4.3.2, and that several "tuned" binaries were available for 486, 586, 686. Available from I want to commend Rugxulo for taking the time to compile and distribute this UPX-UCL. I believe software freedom is very important, a core component of FreeDOS. Without software freedom, FreeDOS wouldn't really be free.

My issue with UPX is that I'm not convinced NRV compression can be used with Free software, like FreeDOS. According to the UPX web site:
UPX is copyrighted software distributed under the terms of the GNU General Public License, with special exceptions granting the free usage for commercial programs as stated in the UPX License Agreement.

UPX uses the NRV compression library for compression services. A compatible but somewhat less efficient OpenSource implementation is available through the UCL compression library.
Looking further, I understand that UPX uses NRV, but NRV is not available under the GNU GPL. I have always been wary of this, because the GNU GPL is very clear that linking GPL'd code with non-GPL'd libraries is not allowed. Yet the UPX site says:
The stub which is imbedded in each UPX compressed program is part of UPX and UCL, and contains code that is under our copyright. The terms of the GNU General Public License still apply as compressing a program is a special form of linking with our stub.
I asked the Free Software Foundation folks about this, and was told basically, this is allowed, and doesn't present a problem for compressing programs that are under the GNU GPL. The FSF compares this to packaging a GNU GPL program with a non-free packager. But they encourage using an all-free solution instead.

So it's an important milestone for us that we now have a UPX-UCL available for FreeDOS. Having an all-free UPX-UCL removes the questions surrounding this issue. I encourage all FreeDOS developers to use this UPX-UCL rather than any version of UPX that uses NRV. Above all, I ask that FreeDOS developers choose the UCL method to compress your programs, where you use UPX to compress your binaries.

Sunday, February 8, 2009

Applying to grad school

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.

Saturday, January 31, 2009

FreeDOS Wiki update

Okay, it looks like the FreeDOS Wiki isn't tweaked right, at least for allowing users to edit. A few of you have emailed me to let me know you cannot edit the Wiki, even though you have a SF login. Ideally, any user with a SF login should be able to edit the Wiki.

I've gone through the Wiki settings, and I can't see what's wrong. So I've opened a support request, and hope to have this resolved in a few days.
Update: While I thought permissions were wide open, SF confirms that you need a wiki account to edit the Wiki. This is to prevent spamming. They have raised this as an enhancement request. In the meantime, if you want to edit the FreeDOS Wiki, please create a wiki account for yourself, then request an admin to allow you to edit.

Thursday, January 29, 2009

You can help

If you're looking for a status update on the FreeDOS 1.1 distribution, here it is:

Not done yet. We're still working on it. We need help. Coming soon!

We're looking for help in putting together the FreeDOS 1.1 distribution, and that means you! What's in the queue before we can roll out the "1.1" distro:
  1. Mateusz has the new FDUPDATE but you cannot (yet) use it to update from FreeDOS 1.0 to "1.1", since not all the clean zip packages have been completed. Check the package list to start.
  2. We need someone to assemble the FreeDOS 1.1 packages. This will probably be related to the FDUPDATE work.
  3. The updated Installer hasn't been worked on. Not sure this is going to happen for the release. Aitor may be working on it; please contact him to contribute.
Additional features of FreeDOS 1.1:
  • Fritz is almost done with the new update for HTMLHELP, including German and English texts. Needs proof-reading. Email freedos-devel if you can help.
  • Brian's new FDISK needs testing. It's currently at version 1.3.1.
  • The FreeDOS bug database (a separate list is also at the FD-DOC wiki) shows all known problems with FreeDOS 1.0. Contact a developer through the Software List.
  • We also need help with testing, especially as we get closer to making a pre-release.
For FreeDOS 1.1, we aren't planning any major changes. This will pretty much be an update to the 1.0 release, but with a new Update program, an optional floppy-only "Base" install, and (hopefully) a few updates to the Install program. Let's worry about other, larger changes in later releases.

Friday, January 2, 2009

FreeDOS Wiki

Previously, I wrote about the FD-DOC site move. So the time has come to migrate away from FD-DOC, and start managing everything "centrally". We have a MediaWiki provided for us by the kind folks at SourceForge. For the last 2 weeks, I've been copying & pasting documentation from FD-DOC into the Wiki at SourceForge, where it is more visibly part of the larger "FreeDOS community" - where everyone can help to contribute, and it's not in just one person's hands.

I'm happy to report that I've finished this important milestone - the HOWTOs, mini-HOWTOs, the FreeDOS Spec, and FreeDOS Manifesto have been migrated into the FreeDOS Wiki! How the old FD-DOC Wiki maps into the new FreeDOS Wiki:

FreeDOS Wiki

  • Main Page- FreeDOS Information Sheet


  • Howto- list of all HOWTOs
  • Laptops- FreeDOS on Laptops
  • Games- Gamers How To
  • Network- DOS Networking HOWTO
  • Advocacy- FreeDOS advocacy How-to
  • Coding- FreeDOS Coding How-to
  • Contribute- FreeDOS Contribute How-to
  • Install- FreeDOS install How-to. Also includes FreeDOS with VirtualPC Mini How-to, by Renee Brandt.
  • Package- FreeDOS package How-to
  • Patching- Kernel patch submit How-to


  • 3Com- 3Com Packet Driver Mini How-to, by Jóhann "Myrkraverk" Óskarsson
  • Subversion- SVN at SourceForge Mini How-to
  • Distributions- FreeDOS Distribution Mini How-to
  • International- FreeDOS International Support Mini How-to
  • NFS- FreeDOS NFS Networking Mini How-to, by John Harrison
  • Htmlhelp- Html Help Tags
  • USB- USB Boot Disk, by Rui Miguel Silva Seabra . Merged with USB Boot Disk with Windows Vista, by freedosuser.

FreeDOS Spec

  • FreeDOS Spec- the FreeDOS Spec
  • Bug tracking system- appendix to the FreeDOS Spec
  • Config.sys- appendix to the FreeDOS Spec
  • Country codes- appendix to the FreeDOS Spec
  • Dos commands- appendix to the FreeDOS Spec
  • Extension commands- appendix to the FreeDOS Spec
  • Internal commands- appendix to the FreeDOS Spec
  • Ralf Brown's Interrupt List- appendix to the FreeDOS Spec

FreeDOS Manifesto

  • Manifesto- the FreeDOS Manifesto (English only)

For those that are curious: the next step will be to go through these Wiki entries again, and split out topics into separate entries. For example, the entry on DOS commands contains a list of every FreeDOS/MS-DOS command, including its usage. It would be better to have a separate Wiki entry for each command. But this will take some time, and I'll need your help. If you're interested in contributing, all you need to edit the FreeDOS Wiki is a username on SourceForge.