About
Code by Kevin: Programming, code, business, and other pursuits

Your Host
Kevin Walzer, software developer.

Home

Subscribe to RSS Feed
Get a syndicated feed of my weblog.

Free Software Isn't Free: Or, Why A Solo Developer Must Charge a Fee for Open-Source Software

Today I'm releasing version 1.0 of my open-source GUI for the DarwinPorts package management system for Mac OS X, Port Authority. This is a milestone release: Port Authority has been under active development for two years, has attained a large user base, and is now a stable, feature-complete, and well-documented program with an attractive user interface. Importantly, it is also now a universal binary, meaning that it runs natively on both the Mac's new Intel architecture and legacy PPC architecture.

There's one significant difference between this version and previous releases, though. Before, I made the program freely downloadable, for no charge, from its project page at the SourceForge open-source hosting service. However, starting with version 1.0, I am providing a free download only for the Unix-based X11 version, and charging a download fee of $6.25 for the Mac-native Aqua version--the version that most users will want to install.

I expect that this will upset more than a few of Port Authority's users. Not only are they used to getting the program for no cost, but it's unusual to charge any kind of fee for open-source software. Frankly, it's difficult to charge a fee to end users of an open-source application. The availability of the program's source code means, among other things, that savvy users can assemble and run the program themselves, without any assistance from the program's developer. Also, many developers of open-source software simply don't want to charge any kind of fee; they are often creating open-source software to be a direct alternative to commercial, "closed-source" software--which almost always charges fees to its end users and almost never comes with user-modifiable source code. (This has been a large part of my own motivation as a software developer over the past two years.) Taken together, these facts create a strong market pressure against charging fees for open-source software.

Still, I have reached a point where I believe that charging a fee for Port Authority is necessary--for both myself and the thousands of people who are users of the program. I'd like to explain why in more depth.

Free Software Isn't Free

Open-source software may typically be free to download, but it's certainly not free to develop. In my case, it takes a non-trivial amount of time, and also incurs some monetary costs.

For instance, it's taken me nearly six months to rewrite Port Authority as a "universal binary." While Port Authority's programming language, Tcl/Tk, is very portable and Tcl/Tk has been available as a universal binary for several months, I also used several Tcl/Tk libraries that could not themselves be ported to the universal binary format. (Specifically, I'm talking about modules compiled with critcl, which is not yet publicly available as a universal binary.) Thus, I had to rewrite a substantial amount of my code to eliminate these dependencies, and do a lot of my own custom software builds to create an appropriate setup for working with universal binaries. (One providential result is that I've released a lot of the resulting code for use by other developers.)

As someone who is self-employed and supports my family from my work, I understand as well as anyone that time is money. As my children grow up, it's increasinly hard for me to justify investing a significant amount of time on anything that does not help put food on the table or keep a roof over their heads. I don't want to stop working on Port Authority, or the other open-source projects I'm involved with (most of which have been undertaken in support of Port Authority, for instance to expand my range of programming techniques or knowledge, or to be directly used by PA). Yet I can't keep working on it in a purely volunteer capacity.

In terms of actual monetary costs, my G3 iBook is on its last legs; it recently went into the shop for the fourth time for a faulty logic board. which shorts out the display. A new laptop is essential for continued development of Port Authority, and MacBooks aren't cheap.

If the development of Port Authority provides no financial renumeration, or even worse, consumes extensive financial resources out of my own pocket, it's hard to justify continuing to work on the program. It's that simple.

Financing Open-Source Software: A Common Dilemma for Solo Developers

I'm not the only open-source Mac developer to wrestle with the question of how to make a living, at least partially, from his or her work with open source programming. My friend David Reitter, the developer of the Mac-native Aquamacs port of Emacs, has been having public discussions with the users of his program for several months on the best way to do this. (David currently solicits monetary donations from his users, but this doesn't yield much revenue--more on this in a bit.) Similarly, Patrick Luby, the developer of NeoOffice, the Mac-native port of OpenOffice.org, has implemented a paid early access program for new builds of NeoOffice, in part because users' monetary donations weren't enough to support the project.

The issue here is simple: making a living. Like anyone else, programmers need to put food on their table. While my main business is successful and keeps a roof over my head, I want the work I do with software to contribute financially to my family. And the choice is more stark for developers such as Luby, who program full-time: they must often choose between taking consulting work or working on their open-source projects.This isn't a matter of being greedy or "selling out." I was drawn to open-source development because of its ideals: the availablity of source code helps users to ensure that they will be able to maintain control of their computing environments, and the community-driven development of major software projects helps to ensure more rapid, less buggy products. I haven't given up these ideals; I'd like to honor them and still make a living.

Developers of proprietary (closed-source) programs don't face such dilemmas; they charge fees, sometimes hefty ones, to use their software. They have the usual business challenges of developing a large enough user base to bring in adequate revenue, but they aren't bothered by the prospects of closing their source code. In fact, many proprietary developers are downright hostile to the concept of open source software. Unlike me, they want to keep their code closed.

For what it's worth, many of the largest open-source software projects have corporate sponsors, and the lead developers on these projects are paid to work on them. One example is Sun, which sponsors OpenOffice.org, as part of its strategy to compete with Microsoft. Such sponsorships are very helpful, even essential, to open-source software, but they are not very relevant to solo developers of smaller applications like Port Authority.

Why Not Solicit Donations?

Many open-source software projects solicit financial donations from their users. Aquamacs and NeoOffice do so explicitly, popping up a "nag screen" whenever a user launches the latest version of the program. (A "nag screen" is a dialog box that asks users to support the program with a donation or, in the case of closed-source software being run as a demo, to pay a licensing fee to unlock the program's full functionality.) I've also tried this in a more quiet way with Port Authority in the past, putting up a donation link at the project website.

Asking for voluntary monetary donations by end users seems, in theory, to be a good way to finance smaller open-source software projects. Such solicitations tap into the community nature of an open-source project by asking the community for support; also, because open-source programs are not crippled or limited unless a donation is made, this avoids one of the more onerous features of commercial software. Still, donations are a better idea in concept than in practice.

Most importantly, I have yet to see an open-source project earn more than small amounts of money from donations. It isn't hard to see why. Users have no real incentive to donate. They already have the fully functioning program; in most cases, donations will not obtain them any additional benefits from the software itself. Additionally, despite the warm connotations of the word "donation," donating money to an open-source project isn't the same as a charitable donation (with the accompanying benefits of a tax deduction), because individual software developers are usually not established as non-profit organizations under tax law. (Some of the largest software projects, such as the Free Software Foundation, are incorporated in this manner, and a contribution to these organizations is tax deductible.)

So: a donation to the development of Port Authority through its SourceForge project site might give the donor a warm, fuzzy feeling, but not much else. The user already has the program, and the user won't get a tax write-off. I don't see soliciting donations as a very productive path.

If Not Donations, Then What?

In order to convince users to pay to support Port Authority's development, I have to provide something of value in exchange for that payment. While the answer to this question might vary for other projects, my answer is this: Provide the Aqua-native build in exchange for payment. This is what the vast majority of the program's users want--an easy-to-install, Aqua-native verison of the program. So, that's what they'll get.

As I noted, the X11 (Unix-based) version of Port Authority is available as a free download from Sourceforge. It is fully functional, and comes with complete source code and build instructions. (The source code for both versions of Port Authority is identical.) The only difference from the Aqua version is the user experience.

The easiest way to obtain the Aqua user experience is to pay the download fee of $6.25, and then download the Aqua version from Lulu.com (see the Port Authority site for the download link). You'll get the Aqua-native version, source code, build instructions, and all the rest. I certainly don't think the download fee is unreasonable--$6.25 is cheaper than most shareware, and I've chosen Lulu to handle payment and fulfillment because it's the most simplest, most inexpensive service I've found--and you'll get the convenience of the pre-packaged Aqua version.

If you don't want to pay the fee, either for budgetary or philosophical reasons, you can still get the Aqua version--but you'll have to invest time in building it yourself, or tracking down an unsupported alternate build, should someone choose to make it freely available. (It's completely legal under Port Authority's license to redistribute the Aqua build yourself. The only thing you can't do is close the source, since I've changed the license to the GPL.) I realize that I am at risk of competing with a free version of my own program. That's a risk I'm willing to accept.

Port Authority Is Still Open Source--But It's Not Freeware

The various download sites where Port Authority is typically listed will no longer say "freeware." It will list a price of $6.25 for the program, and I will probably have to list it as "shareware"--simply because the language of download sites is not compatible with the language of open-source software licensing. But I am not closing the source of the program. In fact, I've changed the license from its prevous BSD-style license to the GPL so the source will never be closed.

This promises to be an interesting experiment. If it's successful, then I hope other open-source software developers might decide to emulate it. If it's unsuccessful, I'll have to evaluate how--or, more specifically, whether--I will invest my own time as a developer. But, I'm hopeful--even optimistic--that I won't have to make such an evaluation. Time will tell.

[/software] permanent link