Someone called Brian just posted a very interesting comment on my blog; specifically, he asked

I would never create a software and then give it away for free. What is the point? How am I going to get a reward for the work? If a dentist filled teeth for free he would die of starvation, wouldn't he?

The reason that I say this is interesting is that people have very different views on the subject. I’m currently working on some commercial software of my own (well, actually, I’m in the run-up to selling it… it’ll be on the market this month), but in the past I’ve worked on both freeware and Free/Open Source Software, so I thought I’d explain my motivations for doing so.

Freeware that I’ve released in the past includes:

• A Yahtzee-like game for the Atari ST, implemented as a desk accessory.

• WinPager, which was a desktop switcher for Microsoft Windows.

• qccdasm, which disassembles compiled Quake C code so you can see how it works.

Interestingly, I managed to lose all the sources for the above. Still, I don’t use those platforms at the moment so it doesn’t bother me too much.

So why did I write those programs? Well, mostly because I wanted them. I know, it’s hard to imagine someone needing a Yahtzee game, but at the time I thought it’d be nice. And why didn’t I sell them? Three reasons, really:

1. I didn't think they were worth anything. Or rather, I didn't feel that the amount that they were worth justified the hassle of selling them.

2. I didn't want to have to provide the level of support that people are reasonably entitled expect from commercial software (even shareware).

3. I didn't feel that I was likely to continue developing them in the long term. This is related to the support issue, in many ways.

So, that’s freeware.

How about F/OSS? I’ve worked on two F/OSS packages and submitted patches for a third, specifically:

• I did a lot of work on GCC to make it work as a native Win32 compiler, including better __attribute__ support in C++, anonymous structs (and anonymous unions in C), and MSVC-compatible #pragma pack() support. I even had some scripts at one point that could patch the Platform SDK so that it worked with GCC (well, to some extent, anyway). Of course, others have taken the work that I did and improved upon it, fixing mistakes that I'd made or modifying the code to be acceptable to the maintainers.

• I've also submitted patches for GCC for a few other features, like being able to specify the instruction sequence to use for a function call (this is useful on PalmOS and Atari platforms, where system calls use trap instructions rather than plain branches).

• I rewrote large chunks of the XEmacs clipboard code so that it could support multi-format clipboards (like on Windows and the Mac).

• I also wrote an RTF package for XEmacs, that allows you to export RTF from a formatted buffer, preserving all of the fonts, colours etcetera. This plugs-in to the enhanced clipboard support and means that, on Windows, you can copy syntax-highlit code to the clipboard… which is a boon for people who write design documents as it makes them a lot easier to read for very little extra effort.

• I wrote code to implement rlog and list commands for CVS (where rlog means remote log, rather than a synonym for log). I don't think the code that implements the rlog command in newer versions of CVS is actually mine, although I don't know.

Looking at the above, you'll probably see that I tended to contribute to F/OSS whenever I needed it to do something that it didn't already do. Perhaps that makes me mercenary? Or maybe just pragmatic?

I've worked on commercial software too, for my previous employer, Telsis Limited, who make telecoms switchgear, SMS handling kit and those kinds of things. And I'm currently working on my own commercial software. Actually I've pretty much finished working on it and I'm onto the more commercial side of things now.

Doubtless RMS and ERS would argue that there's no future in commercial software; I don't really agree. I, like many others, think that there's probably no future in fully commercial operating systems, at least not unless Microsoft successfully manages to obtain legal protection for its monopoly, through whatever means (software patents appear to be the current favorite). I'm a little dubious that F/OSS will eventually subsume all other software development methods however. For one thing, people like me have to earn a living, which isn't realistically going to happen if we can only sell support.

For another, there's no clear motivation, particularly for those fortunate enough to possess some level of talent at graphic design or UI design as well as (or instead of) coding. Put another way, graphic designers and UI designers can't sell support. There's no incentive for them to work on F/OSS; UI design is hard, takes a lot longer than many people think (well, it does if you do it properly), and only takes a moment to destroy.

I actually think this is the key area were F/OSS falls down. It's very good in areas that academics, computer scientists and programmers are interested in. Where it isn't so great is on the desktop; most of the GUIs that I've seen from the Linux community in recent times have been poor copies of Microsoft's user interfaces, partly, it seems, by design. Microsoft themselves were never tremendously good at UIs, although they are a damned sight better than a lot of the professional programmers working on their platform.

I'm actually intrigued as to the reason that the Linux community, which is usually very anti-Microsoft, has decided in both of the major desktop projects (Gnome and KDE) to produce what is essentially a clone of the Windows UI. I wonder whether it's because the only UI experience that has been shared by many of the developers is that of Windows (or Motif/CDE, which, somewhat horrifically, was based on Windows 3.1). However it came about, I think it shows a lack of vision as regards UI design, and I don't think it helps the chances of Linux as a desktop operating system.

Anyway, John Gruber's excellent Daring Fireball articles say it all… take a look at Ronco Spray-on Usability and the corrections and clarifications.