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
Many software developers find themselves gravitating to a specific market niche: in other words, their software focuses on a narrow set of related problems. In my case, I develop graphical interfaces for Unix-based command-line tools. In most instances, the Unix programs themselves are free and open-source. In many instances, my own programs compete with applications that also provide a GUI for these command-line tools; the other GUI programs may themselves be free and open-source as well. My programs, of course, are closed-source (proprietary) and cost money to license for full use.
I've seen some grumbling about my approach among open-source developers. They seem to think that all software should be free and open-source. In fact, I've seen more than one programmer vow to write a free application that competes with one of my own; it seems they want to put me out of business. Some actually claim my approach is unethical--as if charging money for software was morally wrong.
When I was first learning software development, I was something of an open-source zealot: I didn't understand why anyone would want to keep the code of their software closed, or demand payment for it. It wasn't until I had been programming for a few years that I decided to turn it into a business; I have a family to feed, and I wanted something that I invested so much time in to help support my family. After experimenting with a few different approaches, I settled on a traditional shareware model. I'm pleased with this approach and will continue with it.
There's nothing morally wrong with charging money for the software I develop. My software runs on top of free/open-source tools; I'm not lifting code from these programs in violation of their license. Many, many end users feel that my software provides a useful benefit to them; that's the entire purpose. I can definitely say that earning part of my living from software develoment is the best guarantee that my programs will continue to be developed and improved. I can't say that for many of the free/open-source programs I have developed. Without a financial incentive, it's easy to abandon a project once you lose interest in it. I noted previously that one popular open-source program that I compete against has barely been updated in four years. That's certainly not the case of any commercial program I develop.
So, to any and all free/open-source developers who want to write software that competes with mine: welcome to the market. If you create a compelling and useful program, good for you. If you stay over the long term and continue to develop it, more power to you. End users certainly benefit the most from having a variety of choices. But I'm not going anywhere, and I will also continue to develop and improve my programs.
Phynchronicity is similar to another application I develop, PortAuthority: it aims to provide an easy-to-use graphical interface to command-line tools for installing Unix software, which can be intimidating for many users. (In the case of PortAuthority, the software management system is MacPorts.)
The main difference between Phynchronicity and PortAuthority is that Phynchronicity is competing against a long-established, polished, and free application: FinkCommander. (PortAuthority, at present, pretty much has the MacPorts GUI field to itself.) When I first started delving into the world of Unix software four years ago, FinkCommander and Fink were among the first things I installed. FinkCommander, in fact, was the inspiration for early versions of PortAuthority.
As time went on, however, I found myself growing increasingly impatient with FinkCommander. It doesn't quite do enough to simplify Fink, in my view. Instead, it presents the user with an almost overhelming array of options. For instance, you can install software from source code, or from pre-compiled binary packages. Its slim (and old) documentation doesn't explain which approach is better (although you can delve into the Fink documents itself to figure this out). It provides too many different ways to update the Fink infrastructure itself. Browsing and searching the Fink database is somewhat difficult with FinkCommander. Finally, FinkCommander is something of an orphan: development on it pretty much stopped in 2003, with only a few bug fixes since then, and a release update as a universal binary that added no new features.
So, I felt there was room to improve on FinkCommander. I designed Phynchronicity with the familiar three-pane interface that is so popular with e-mail programs, newsreaders, and so on; this make browsing Fink packages much more intuitive. I've also deliberately minimized the number of options for the end user; in fact, Phynchronicity currently has no user preferences at all. (This will be phased in over future releases.) And finally, I've tried to install a basic documentation package that will grow and evolve with each new release of Phynchronicity.
So, there you go: if you want to try an alternative to FinkCommander, now you have one. I'm eager to hear what you think.