Code by Kevin, Programming, code, business, and other pursuits
Kevin Walzer, software developer.
Subscribe to RSS Feed
Get a syndicated feed of my weblog.
Site design: Skeleton
As I said previously, my concern about learning a new programming language from scratch is that even with a head start--having the Tk GUI programming model etched in my head, thus making part of the process a matter of translation to the new language rather than learning an entirely new approach--it would be time-consuming. I wouldn't know the best way to do things, I might run into unexpected speed bumps, and it would just generally be a step backward.
That's proven to be the case, in some ways. Programming a Tk GUI is harder from Python than from Tcl, my main programming language. There are little differences in how things are done, some cool things just haven't been translated from Tcl to Python yet, and I've had to find some new ways to accomplish things that are easy for me in Tcl.
Furthermore, I've had to adjust to the different language itself. Python is a very different language from Tcl, I'm discovering. Despite some similarities, there are more differences than I expected.
So PacketStream isn't ready yet. I had done a rough prototype of it in Tcl, but rewriting in Python is more than just a matter of translation. There's a "Python way" of doing things that differs from the "Tcl way," for better or worse.
I don't want to bore you with the technical details, but I'll offer one example. Tcl is generally termed a "procedural" programming language. You write code that does stuff to data, and organize your code around the functions, or procedures, that it follows--in other words, the way the program does stuff.
Python, by contrast, is an "object-oriented" language. You can write Python code in a procedural fashion, but code tends to fall more easily into "object-oriented" organization--in other words, into categories in which related procedures and data are collected together. In procedural programming, the relationship between data and functions is more or less arbitrary; in object-oriented code, there is some conceptual or logical relationship between all the stuff in a single object category (or "class").
There is a lot of arguments among programmers about which is better, procedural or object-oriented programming styles. All I can say is that object-oriented is more complex, especially up-front; it may pay off later in large-scale projects.
My first take at PacketStream (as well as some smaller little projects) was to write Python in a procedural fashion. This is very natural for me in Tcl, but in Python I kept tripping over my own toes. So I eventually decided to re-write PacketStream in an object-oriented fashion, using classes.
It's not complete yet, but I can say that it's going more smoothly than the procedural version of PacketStream did. So I'm glad I decided to give Python and object-oriented programming a try; it definitely feels like I'm expanding my skills (by developing proficiency in a new langauge) and also expanding the breadth of possible solutions to a particular programming problem that might present itself to me.
I'm still not convinced that Python is the solution to every problem; I still find Tkinter too limiting compared to programming a Tk GUI in Tcl. I think if I need to develop a really sophisticated or complex GUI in Tk, I can do that more easily from Tcl than Python. I also believe I can develop more quickly in Tcl than Python, at least right now. But Python is an incredibly robust language, with a large standard library and many extensions, and can do some things that Tcl simply cannot; there's at least one unreleased application on the product list at my main website that would probably lend itself much better to Python than Tcl.
So, when I release PacketStream (hopefully in January), it will look very similar to the other applications I've already released. But under the hood, it will be very different.Wed, 15 Nov 2006
Based on customer feedback, I've decided to make discounted upgrade licenses available to individuals who used versions of PortAuthority, NameFind, and VuMan prior to version 1.1. Yesterday, I had said that these folks would have to pay full price for the new version.
This policy applies to folks who purchased the $6.25 versions of these programs from Lulu.com, and also folks who downloaded a free version of the program from SourceForge.net (Aqua or X11).
This is my way of saying "thanks" to those of you who have used these programs in the past. I hope some of you decide to continue supporting their development by upgrading.Tue, 14 Nov 2006
Moving to a standard serial number registration scheme on my software products has required me to make a clean break with my previous upgrade policies.
I am no longer providing updaters for older purchased versions of my software. This means that folks who purchased the $6.25 version of my programs (PortAuthority, NameFind, and VuMan) will have to purchase a serial number to unlock the latest version.
If you purchased the more expensive version of my software from Lulu.com ($12.50 for NameFind and VuMan, $18.75 for PortAuthority), I will provide a free upgrade license. Just contact me with proof of purchase and I will provide the appropriate serial number.
I know this will make some people unhappy, but those of you who purchased the $6.25 version got a real bargain. Those versions of the software should continue to function fine. The serial number approach will provide a cleaner upgrade path moving forward.
I've released new versions today of PortAuthority, NameFind, and VuMan. All three programs feature nicer interfaces, integration with Apple Help, and other goodies. Check them out, and if you like, buy a license!
There's a lot of discussion on Mac blog sites these days about how many new applications have adopted an elaborate, baroque interface design that, when done well, is simply dazzling: eye-candy from the richest candy store in town. One blog terms these apps the Delicious generation, after the hugely successful (and hugely influential) Delicious Library program, a tool for managing and categorizing collections of DVD's, songs, games, and so on.
I have one word for the Delicious generation: blecch.
I think many of these applications represent the triumph of style over substance. They tend to be overdesigned, fussy, and often (as some report about the case of one new program) so thick with eye candy that they are near-unusable. What's worse, as these applications proliferate, they run the risk of turning the Mac into Linux: a hodgepodge of inconsistent user conventions, appearances, and more, with everyone doing his/her own thing and everyone trying to layer on the lacquer coating.
While some suggest that making ever-slicker apps makes the Mac more appealing as a computing platform for new users, I'm not encouraged by this trend. What has historically made the Mac a superb platform to work on is not how "slick" its applications look, but by how consistently they work--following Apple's Human Interface Guidelines. Apple has spent a great deal of time researching and implementing these guidelines, and when intelligenty followed, these guidelines ensure a very consistent user experience from one app to the next. That's important. Usasbility has to be designed into an application from the beginning. It's not something you slather on at the end, as many Linux developers seem to think.
The problem is that no one seems to be following the HIG anymore: not even Apple. A lot of Apple's new apps, such as its high-level graphics programs, don't follow the HIG at all. And this places some developers in a conumdrum: do you do as Apple says (via the HIG) or what Apple does (via many of its new apps)? A lot of developers are opting for the latter, trying to infer a workable set of guidelines from Apple's own example.
My own approach in designing my apps has been to follow the HIG as much as reasonably possible, and opt for a conservative approach that gets out of the user's way, rather than in the user's face. In looking for a model to emulate, I've chosen not one of the "Delicious generation," but rather Brent Simmons' NetNewsWire. I consider NetNewsWire to be a superb example of interface design, one that is clean and attractive, but also intuitive and usable: in short, it gets out of the user's way. It is a model of simplicity and elegance. Its design philosophy, often stated by Simmons at his blog, is that the program is finished not when there is nothing more to add, but when there is nothing more to take away. In short, the program has been distilled to its purest essence.
I don't claim that my own programs meet this standard, but that's what they strive for. Much of the work I've done on them has focused on refining their interfaces rather than adding tons of new features. I think the new releases come closer to emulating the example of NetNewsWire than previous versions do. (You can judge for yourself by going to my main software page.)
I do have one challenge in following the HIG, in that the HIG is geared for developers using Apple's tools. In my case I sometimes have to design things to emulate the HIG as closely as possible, rather than getting some of its goodies "for free." Sometimes this also requires me to abandon work I've done on my programs that doesn't meet the HIG. For instance, I spent several months developing a help viewer to use in my programs that would work in a cross-platform manner; this help viewer represents a lot of work, and I'm proud of it. However, Mac users expect the native Apple Help viewer in their programs, so I've adopted my user documentation to meet that standard (and use those Mac-specific programming API's).
Still, I don't think you'll ever call my programs "delicious." And that's fine with me. I'd rather be usable than delicious.Sat, 11 Nov 2006
You also may notice the new domain name, the new look to the site, and (if you check the application pages) the new look to the applications themselves. You also may notice a lot more applications on the drawing board.
Finally, you may notice a different method of purchasing my software: instead of downloading a separate full version after purchasing, you can use a standard shareware license/serial number to unlock the demo version. This will simplify the upgrade process for my applications; the previous system didn't provide a convenient path to upgrading.
These changes represent a desire to move in a more professional direction with software development. I want my programs to look nicer, work better, and be easier to purchase and upgrade. I'm committing to this as a business. If folks are going to be comfortable parting with their money to use the software I write, then they have a right to expect a serious, committed developer behind his products.
If you read this blog, as well as earlier iterations of my blogs, you'll see a lot of discussion about business models, business directions, business practices, price points, and so on. That reflects my own education in the business of software, which is a distinct topic from the development of software.
I'm at a point now where I am comfortable with the business framework I've created. I understand the benefits of adopting a traditional shareware model, as opposed to trying to blaze new trails with open-source software. (For what it's worth, I still maintain and update a lot of open-source components.) I believe this approach offers the best potential for me to earn good revenue from software development--and in turn continue the development of useful programs.
I've talked previously about sales. How have sales been? Slow, but steady. I see that as a good place to start. My challenge now is to create and support software compelling enough to pay for--software tools that provide maximum value for the dollar. I'm looking forward to it.Sat, 16 Sep 2006
After closing the source of my software programs, introducing a 30-day demo period, and raising prices, I've noticed that sales have slowed down quite a bit. I think this is because a) a longer evaluation period and b) higher prices are going to lengthen the sales cycle. Downloads of the demo programs continue to be good. So, I'm going to be patient; I'm confident that sales will go back up after the 30-day sales cycle has fully started.
One thing I have been looking at is whether I should expand or change my programming approach. My main programming language is Tcl/Tk, supplemented by AppleScript. Tcl/Tk is a powerful, flexible, yet simple cross-platform tookit that has provided everything I need to develop complete applications. I've been programming in Tcl/Tk for two years, and I've developed a decent level of competency in it. AppleScript, which was my first programming language, is a good complement to Tcl/Tk; it's not really suitable for full-scale programs, but it's good for hooking into the Mac OS for specific things, and is also good for very simple applications that don't do very much. (For instance, I create my program updaters in AppleScript; they provide a simple GUI to update my applications.)
The main drawback of Tcl/Tk is that, as a cross-platform toolkit, it doesn't take advantage of some advanced bells and whistles of Mac OS X that are typically featured in commercial applications. It takes more work to get a Tcl/Tk program looking good on the Mac than it would if I were using a platform-specific programming environment (specifically, Cocoa, which is the Apple-recommended programming framework).
This has, at least to some degree, gotten me wondering if my choice of programming toolkits is somehow affecting how well my programs sell. In seeking feedback from other independent Mac developers about my programs, many of them simply say: "Learn Cocoa"--as if nothing else needs to be said. If a program is Cocoa, it's gold; if not, it's not.
I find it difficult to embrace such advice, for several reasons. One, Tcl/Tk isn't compatible with Cocoa; the Mac version of Tcl/Tk is built on top of Apple's older Carbon frameworks, which date back to the old Mac OS and aren't updated as frequently--or promoted nearly as heavily--as Cocoa. So learning the Cocoa frameworks would require me not only to learn a new programming environment, but also a new programming language.
Learning a new programming language is a non-trivial process. It's taken me two years to develop a reasonable degree of proficiency with Tcl/Tk--to learn how to use the language to solve problems, and to develop a useful repertoire of techniques. I can now develop a Tcl/Tk application pretty quickly, and if there is something in the language I don't know how to do, it's fairly simple to read up on that aspect of the language and incorporate it into my knowledge base. But a new programming language puts you back at square one. Each language has a different approach to solving problems, and expertise in one language doesn't give you instant expertise in another.
I gained some insight into this issue this week when I was actually updating one of the few open-source projects I still maintain--a new version of AquaEthereal, a small program that launches a popular Unix-based network monitor with a double-click. I wrote AquaEthereal in Python, a language with similar capabilities to Tcl--and which also can be use with the Tk tools for creating graphical interfaces. I've dabbled in Python but have not found a compelling reason to delve into more deeply, because it's pretty much a peer to Tcl in terms of what it can do. I decided to try and give Python a greater workout with the new version of AquaEthereal by using Tk for the GUI rather than the simple built-in dialog boxes ("EasyDialogs") that the earlier versions of AquaEthereal used. What I found, though, frustrated me. Much of the advanced Tk stuff that I commonly use in my Tcl/Tk programs can't be used from Python, or is only available with a huge amount of work; Tk on Python lags far behind Tk under Tcl, where the cutting-edge techniques with GUI development are used. After putting together an ugly, incomplete, and much more complex version of AquaEthereal using Python/Tk, I finally gave up and reverted to EasyDialogs. It just didn't seem worth the time it would take for me to re-create, in Python, the advanced stuff I already use without difficulty in Tcl.
If I were still an open-source developer, doing this strictly for fun, I'd say fine--I can take as long as I need to learn new stuff. In fact, learning new stuff is one of the chief reasons to do open-source development. Python has Cocoa bindings, and they are highly recommended by some programmers. But learning Python, and Cocoa, would be incredibly time-consuming. Now my goal is to earn, not learn. And that means using what is most productive for me as a programmer--to keep improving my older applications and creating new ones.
It's a much simpler process for me to keep polishing and refining my Tcl/Tk applications to provide the best possible Mac user experience than it would be for me to scrap all the work I've done over the past two years and learn a completely new approach. If it's hard to learn Tk from Python--where the language is different but the GUI toolkit is nominally the same as Tcl/Tk--then I can only imagine how long it would take to learn Python/Cocoa.Tue, 05 Sep 2006
After a lot of thought, I've make a big decision: my end-user programs are now closed-source.I've been a bit of an open-source crusader up until now. This is a sharp reversal in my approach to developing software.
Why do this?
Money. You can skip the rest of this blog entry if you want, since that pretty much sums it up, but I'll elaborate anyway.
Since starting to release my software on parallel tracks this past summer--a free Unix-style version, and an inexpensive Aqua version--I've been pleasantly surprised. Sales have been decent.
But let's be honest: decent sales of a $6.25 product don't translate into substantial dollars. That's a given. So what's the best way to increase revenue? Sell a lot more copies, or raise my price.
With a fully-functional free version available, it's hard to sell in high volume. I'm competing with myself. With a free version available, a lot of people are just going to use that. And with a fully-functional free version available, it's hard to raise prices. I'm still competing with myself.
As Eric Sink, a prominent software developer with roots in both the open-source community (he was the original developer of the AbiWord word processing program) and commercial/proprietary software (he owns a highly successful company called SourceGear), puts it:
Like I said above, you can understand a lot about a company if you know roughly what its gross margins are. For example, understanding gross margin is the key to explaining why most open source companies tend to struggle. Fanatics can argue all day about whether or not open source business models work. Clearly they can, as there are several very impressive companies whose products are available as open source.
However, just as I mentioned last month, this is a situation where the typical programmer's black-and-white thinking doesn't help us find smart answers. The wrong question is "Do open source business ever work?" The right question is "Does an open source approach makes the business of software easier or harder?"
From a strictly financial perspective, I think open source makes things harder. An open source product is a commodity. Your version of Linux is essentially the same as mine. If you try to charge too much of a premium, I will undercut you on price, and people will start getting Linux from me instead. Open source companies tend to operate at lower gross margins. That doesn't mean that open source can never work as a business model. However, no matter what anybody says, if two companies have the same risks and operational costs, the low-margin company is a lot harder to manage than the high-margin company.
That's it in a nutshell. As someone who is self-employed, it's important that I maximize those margins as much as possible. Keeping my programs open-source, and generously offering a free version, meant that my margins would be unsustainably low.
So: it's a business decision to close the source of my programs. The older versions are still out there, with source code available. The new versions haven't gone through a radical transformation. But the crucial parts that I need closed--such as the algorithms that enforce a 30-day trial limit, after which the program won't function--are new. And, going forward, I expect the code base of these programs to diverge from the older open-source ones.
It's a business decision. Nothing more, nothing less. It's a decision I'm free to make, because I'm the sole copyright holder (I have received exactly one patch from an end user in two years of developing software, and that patch was offered when the program in question was licensed under terms that allowed closed-sourcing). Any open-source components that I continue to use will be used in accordance with the relevant license (i.e. the Nuvola icon theme that I use is licensed under the LGPL.)
I'll continue to release some things as open-source--libraries that benefit me and might benefit other developers. And if I modify a program that is already open-source, as I did with AquaTkbibtex, that will be open source. But my main investment of time will be spent improving the commercial software I develop--and growing that business. And my software development will stand or fail on that basis.
It's come to my attention that some people who have purchased software from me via Lulu.com have encountered file corruption--specifically, the disk image (DMG) files for version 1.0 (Aqua) of Port Authority and VuMan couldn't be opened.
If you have experienced a problem of this sort and haven't heard from me, please contact me via the "Your Host" link on the sidebar of this blog; I'll get in touch with you to make arrangements for an alternative download.
By the way, the new versions of these programs that I just released come in a different download format, so file corruption should not be an issue at this point.
I've released new versions of Port Authority, my GUI for MacPorts, and VuMan, my man page viewer. 30-day Aqua demos of each program are available for download, the full programs can be purchased, and free updates for paid users of previous versions can also be downloaded.
I've also released a new program, NameFind, a search utility that focuses on finding files by name on your system. The Mac's built-in Spotlight search technology is powerful, but it's slow and complex, and many users complain about it. My program is a good alternative for users who just want to look for files by name on their system.Wed, 09 Aug 2006
The Price You Pay
An interesting thread on a Mac developers' mailing list about the pricing of software (which I helped to initiate) prompted this blog entry by Daniel Jalkut. This is a question that weighs greatly on my mind, as well, since I have started charging for my open-source programs.
My initial pricing strategy was to price my software cheaply: that is, less than $10. ($6.25, to be exact.) My theory was that this would provide a low barrier for folks who would download the free version but might hesitate about paying. That seems to have worked so far: I'm getting decent sales of my first program, Port Authority. After reading the various arguments in the thread, however, I had initially decided to raise my prices to $20. I even released VuMan at this price point. A few hours later, however--after seeing a complaint that the software was overpriced and, more importantly, recalling why I had initially decided on a lower price point--I lowered the price back to $6.25.
This afternoon, I got my first sale.
Coincidence? Perhaps. Perhaps I'm leaving a lot of money on the table. But I don't think so. VuMan, like the other applications I develop, is open-source, can be legally built and distributed without paying me, and was formerly promoted as a free-as-in-beer program. All of its competitors are still free-as-in-beer. So, if nothing else, an economic analysis of this particular product's market niche shows that there's a lot of downward pressure on prices.
In short, at $20, I was likely to price my program right out of the market. At $6.25, it might be a little on the high end compared to zero, but it's still competitive.
My example may not be relevant for everyone. If you are trying to build a business around proprietary (closed-source) applications, then it probably makes sense to charge as much as the market will bear. Actually, I think I'm doing that also--but my market won't bear very much. If you are building proprietary applications, there is probably a lot of other kinds of overhead that have to figure into your price as well (the cost of icon designers--I use open-source icons; Google adwords--I don't advertise; and so on).
So, as long as I'm working in the open-source vein, my prices will likely be low. If I ever learn Cocoa well enough to release a program in it, perhaps that will change.
I've released version 1.0 of VuMan, my man page viewer for Mac OS X. A freely available version running under Apple's X11 environment is available from http://vuman.sourceforge.net and a native-Aqua version (downloadable for a modest fee) is available from http://www.kevin-walzer.com/software/vuman_aqua/.
I'm happy to report that some users are choosing to download the paid Aqua version of Port Authority. While it certainly isn't a majority of users, it is a healthy percentage--one consistent with numbers reported by successful shareware developers.
To those who have downloaded the paid version, thank you. You are supporting Port Authority's continued development.
And to those who have chosen to use the free version that's available at Sourceforge, thank you also. You have my best wishes, and gratitude for using the program.Wed, 21 Jun 2006
I've released version 1.3 of AquaTkbibtex, my "Aquified" version of the venerable tkbibtex editor developed by Peter Corke. The new release is a universal binary and includes a refined interface for printing documents. It is licensed under the GPL. For more information, see aquatkbibtex.sourceforge.net.Mon, 12 Jun 2006
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.Mon, 08 May 2006
The first program I've released since coming back to coding (this blog is called "Poetic Code," after all) is an updated version of AquaEthereal, a little utility that launches the Ethereal network monitoring program on Mac OS X. Getting Ethereal itself installed is a complex process, and it has to be run from the command line, meaning that you have to type lots of cryptic commands into a DOS-like console (for those of you readers who use Windows). AquaEthereal provides a convenient double-click method for starting Ethereal. The new version, written in the Python programming language, is a "universal binary," which means it will run on both the PowerPC and the new Intel versions of the Mac.
If you've read my blog in its earlier iterations, you know that I'm an avid amateur software developer. My programs have all been free (as in no-cost) and open-source (meaning the source code is available for others to see and possibly learn from). Earlier this year I tried to turn this enthusiasm into yet another business (my day job, as co-editor of WordTech Communications LLC, being the main business) by releasing a "shareware" program--a low-cost, closed-source (meaning the source code isn't available for anyone to see) program. It was an utter failure; I sold only a few copies, the reviews that came in were overwhelmingly negative, and I decided to cut my losses rather than become distracted from my main career, publishing.
After this, I took a long break from programming to decide whether I even wanted to continue programming at all, and if so, in what capacity. I ultimately realized that I enjoy programming a lot--in no small part because it exercises my brain in such a different way than reading and editing poetry--and that I enjoy it most when it's detached from any business considerations. So, I'm easing back into programming, but in my previous mode: doing free and open-source stuff. I program for fun. The itch to release software commercially has been thoroughly, and unpleasantly, scratched.Wed, 12 Apr 2006
I've tried at various times over the past couple of years to maintain a blog site. The first iteration, which was hosted at this domain name, was mainly personal in focus, and I gave it up after the 2004 elections turned blogging into a toxic activity. The second, more recent, iteration focused strictly on my hobby, which is software programming. But that doesn't represent all of me.
So, this third attempt: "meditations on poetry, publishing, software development, and other creative pursuits." It will include things on matters both personal and professional, and will try to attain the same balance that I try to attain in my daily life. (Good luck on that one...!)