About
Code by Kevin: Programming, code, business, and other pursuits
Your Host
Kevin Walzer, software developer.
Subscribe to RSS Feed
Get a syndicated feed of my weblog.
2008
2007
2006
Categories
Business
Software
General
Fri, 25 Jul 2008
Michiel van Meeteren did a research project for graduate school on the independent Mac development community, called "Indie Fever." The paper can be downloaded here.
It's an interesting overview of the community, and it has a lot of good points, but it has one serious flaw: it assumes that the Mac development community is comprised strictly of Cocoa developers. It even goes so far as to assert that independent Carbon development, for all intents and purposes, is dead.
Not true. I can think of several independent Mac developers, including Skytag Software, LemkeSoft, Black Cat Systems, and Fetch Softworks, who should be counted as vital members of the independent Mac development community. They develop with Carbon, or a Carbon wrapper such as RealBasic.
Why weren't these developers discussed at all in this paper? Why does the paper's author automatically equate Mac development with Cocoa development?
Barrier to development on Apple: getting higher or lower?
Many Cocoa developers applaud the increasing emphasis that Apple is placing on Cocoa as the main development framework for OS X. They also believe that Apple is making it easier than ever to learn Cocoa, by adding such features as "garbage collection" to the language (which reduces the amount of effort developers have to spend managing memory), and by directly supporting scripting bridges to Cocoa (specifically, PyObjC for Python developers and RubyCocoa for Ruby developers). The consensus about Apple's lowering the barrier to learning Cocoa is even shared by curmudgeonly Cocoa developers, who grumble that Apple is watering down standards, making it too easy to write Cocoa software, which will lead to lots of bad software.
I'm not sure I agree that Apple is lowering the barrier to entry on Mac development.
All the features that Apple is adding to Cocoa will make it somewhat easier to pick up developing with the Cocoa frameworks. However, the increasing emphasis on Cocoa means that it's now pretty much the only show in town for Mac development. And if you don't write in Cocoa, the migration path to Cocoa is not easy. Anyone doing development based on the Carbon frameworks--either directly or with a higher-level toolkit--has a higher, rather than lower, barrier to entry.
Mon, 03 Mar 2008
Market forces, customer needs, and business success
A couple of developments this past weekend prompted some thinking on my part about the software business, customer needs, and fashion.
First, David Watanabe, a well-known independent Mac developer, announced that he was making his NewsFire newsfeed reader free. Previously it had been a shareware product requiring a registration fee.
Second, Dave Taubler, a cross-platform Java developer whom I've never heard of, released a point update to OverSite, a website-design tool. OverSite is a shareware product that requires a registration fee.
Watanabe is well-known among the Mac user and developer community for, among other things, the elegance of his programs. They are, quite simply, beautiful. They show the full potential of Apple's recommended Cocoa developer frameworks.
Taubler isn't a semi-celebrity in the Mac community. Looking at his website, he appears to have a day job, and develops shareware part-time, using Java as his chosen technology. By contrast to Watanabe, users don't find Taubler's application beautiful.
Why am I comparing these two developers and their software? Because it appears that, although Watanabe has the shinier product--a beautiful Cocoa newsreader--Taubler's plain-Jane Java program is the more financially successful program. How do I reach this conclusion: Simple. Watanabe has apparently concluded that there is no paying market for NewsFire, and has made it free of charge. Taubler, on the other hand, continues to charge for his program.
How can a Java program do better than a Cocoa program on OS X? Such a development runs against every bit of conventional wisdom that one sees in the Mac developer community. I see several reasons for this.
One factor is that markets change and evolve, and in the specific instance of Watanabe's market--desktop newsfeed readers--the paying market is imploding. There are numerous free, web-based feed-reading services, such as Google Reader. There are numerous free desktop readers such as Vienna. And finally, the leading Mac desktop RSS client, NetNewsWire, became free; its corporate owner decided, in the words ofits developer, that "the software is great marketing for our enterprise software; and the more users we have, the better able we are to calculate relevance and importance."
In short: desktop RSS clients are now like desktop web browsers and e-mail clients: a commodity that few users will be willing to pay for. This development hasn't discouraged at least one other developer of a desktop RSS client, but it is clear that this market segment is now exceedingly difficult.
Taubler's market--web designers--is a smaller one, not growing exponentially like the RSS client market used to, but it is also more likely to include paying customers who use the software professionally. Consequently, while there are a number of competitors at several price points, it is possible for a software product with a specific, specialized feature set to find a place in the market.
Another factor in an application's success, apart from its market growing or drying up, is how well the applicaiton works and how well the developer supports the application. Users apparently find Taubler's application functional. It does what they need it to do. Users also seem to find him to be a responsive developer.
Users seem to have some serious issues with Watanabe's approach to customer service and the stability of his programs. I'd say that opinions of his customer service and application stability run as strongly to the negative as opinions of his application design run to the positive.
While one shouldn't base an opinion of a developer or product entirely on comments posted at a download site, those comments do offer useful information--especially if they seem to converge on a consensus. In the cases of both developers, they do: one is considered unsupportive, the other is considered supportive.
So what lesson am I trying to draw here?
The lesson is that there are many factors that influence the success of an application. One's choice of technology is, based on my observation, a minor factor. Making a fetish of your chosen technology, touting it as a feature in itself rather than something that enables useful features, strikes me as misguided. Targeting the right market, offering helpful user support, and most of all, providing a stable application that solves the user's problems--these are the most important ingredients for success.
A beautiful Cocoa design was apparently not enough to make NewsFire a profitable application for David Watanabe--not when the application's market was imploding, and when many users recommended against purchasing the program because of their own experience with customer support. By contrast, although users seem to find Dave Taubler's application a bit unpolished in terms of its design, its specific functionality and the developer's customer support make it a worthy purchase--even in a market segment that offers several alternatives.
This is a lesson I'm taking to heart myself. I have tried to continually improve the design and the functionality of my programs, and provide good customer support. I'm also continually looking at different market niches as I research potential new products to develop. But I'm not continually reassessing the technologies I use to develop my programs--I am leveraging their strengths and working around their limitations, but most importantly I am using them to develop software that customers find useful, and will pay for.
Thu, 24 Jan 2008As part of the new releases of all my software, I've raised their price: from $20 to $24.95. This might raise a few eyebrows, especially since these are all point updates (for example, from 2.0 to 2.1), and the improvements are refinements of existing features and bug fixes, not a laundry list of new whizbang features. Most price hikes tend to come when a program is bumped from 2.4 to 3.0, and when the software vendor can point to "300 new features!"
I believe the price hikes are justified, however. There is value in continuous refinement and improvement, just as there is value in substantial new functionality.
The changes I've made to my products make them first-class citizens on Leopard, for instance. Shiny new 512-pixel application icons, toggling toolbars, full integration with Leopard's new floating "help" window, no more crashes when saving files, and more. And they retain backward compatibility with Tiger, to boot. These changes represent a lot of work over the past few months. Prior to that, my programs underwent a similar course of evolution: not a lot of new features, but dramatic refinements and simplifications in the user interface, as well as improvements and additions to the user documentation, so that they became more intuitive and pleasant to use. And most of these releases were made as point updates, not entirely new versions.
Over the course of a year, this represents a substantial amount of development work in each program--and substantial improvement. When I was testing the software update feature in each of my programs, I unarchived and used versions that were about 18 months old. They had pretty much the same functionality as the new versions, but they were almost painful to use--it's a wonder I sold any licenses at all, at any price.
So the price increase today is a reflection of the increased value of my software. Relative to competing products, my programs are worth the price I'm charging. Their feature set, elegance, and documentation surpass the free competition, and offers a better value than higher-priced competitors.
Mon, 19 Nov 2007Things have been pretty quiet here lately: I still haven't updated to Leopard, but will do so in the near future. I will be making new Leopard-compatible releases of my software at that time. These will focus on bug fixes rather than substantial new features.
Though I haven't released anything for several weeks, I have been doing a lot of coding, and thinking, about the direction of my programs. Part of this process has been learning the C programming language. Learning C has gone smoothly enough, at least to the point where I can read C code and understand what's going on, more or less. That's a necessary precursor to being able to do productive work in a programming language.
Unfortunately, the next step of my roadmap--learning Apple's Carbon frameworks to help enhance the toolkit I use for my programs, Tk--has gone unexpectedly awry. Simply put, there are no usable, modern resources to learn Carbon. The few available books on Carbon programming are generally obsolete, even though they were published to coincide with the release of Mac OS X. Apple has made huge updates to the Carbon frameworks since OS X was released, but no "introduction to Carbon" documents--whether books or provided directly by Apple--reflect these changes. As a result, if you are a newcomer to Carbon and need to rely on a textbook to learn the basics, you will learn only obsolete things, which you will then have to unlearn in order to adapt to the modern approaches.
Whether by design or happenstance, aspiring Carbon developers are being starved of resources they need to learn the frameworks. This, as much as Apple's deliberate decision to make Carbon a second-class citizen for Mac development, helps to ensure that Carbon eventually will wither away.
As a result, helping out with enhancing Tk is starting to look less and less like a viable option. Getting Tk to do what I want--display Mac icons natively, fully supporting drag-and-drop--will require climbing a learning curve nearly vertical in its difficulty. I'm not a C programmer by trade, nor am I really interested in becoming one. I gravitated to Tcl/Tk and Python/Tk precisely because I thought they wouldn't require me to be a C programmer. The amount of work required to become a Carbon programmer in order to enhance Tk is vastly increased by the paucity of resources for learning modern Carbon programming, and makes the entire enterprise simply daunting to me.
So what does this mean for the future of my programs? Well, they definitely have a future. The question is what direction I take them.
Thu, 25 Oct 2007After several false starts, I'm working on adding a third major programming language to my toolkit, complementing Tcl and Python: C. C is the lingua franca of computer languages, a fast, compact, compiled language that is the basis of operating systems (huge portions of Mac OS X, Linux/Unix, and Windows are written in C), other computer languages (Python and Tcl, both dynamic, interpreted languages, are themselves written in C, while such powerful languages as Objective-C and C++ are additions to C), and such workhorse programs as the Apache web server are written in C.
The problem is, learning C is hard--it's much harder, less forgiving than the scripting languages I'm used to working with. It requires the programmer to do such things as manage memory; it forces you to be very strict in how you set up your code. It's also slower to work with. Instead of saving my code to a script file and then running my code in a dynamic language interpreter, I have to compile my code each time; an interpreter runs the code interactively and immediately, which makes it easy and fast to change your code, but compiled code must be re-compiled each time you make a change.
Given these hurdles, I can't say I'm having a lot of fun learning C--even though I'm still doing very basic stuff, and I'm using a textbook by a well-known Mac developer, Marc Liyanage (see http://www.entropy.ch/blog/2004/10/22/Our_New_Book_About_C_Programming_is_Out.html). Working in C reminds me of why I gravitated to scripting languages in the first place.
So why learn C at all?
The chief reason is that scripting languages, for all their power and ease-of-use, have limitations. Their capabilities are baked into the language by C, and if you want to do more than the languages allow, you need to drop down into C. For instance, Tk (the GUI toolkit that I use, with both Tcl and Python) is very flexible and configurable, and I can tweak many parts of it to get my programs looking very native on the Mac. (See here for some discussion of this and a screenshot.)
However, some things can't be done from within the toolkit or language itself: the toolkit itself needs to be changed. A good example is the way Tk displays notebook tabs on OS X. Here's how my programs display notebook tabs:
Does that look a little out of place? Yes, it does--Tk uses a fairly old Apple C function (specifically, the Carbon Appearance Manager API) to display tabs. This particular method has been out of date since Apple shipped Panther (OS X 10.3) in fall 2003. This style of tab still exists in OS X, since removing it might cause programs to break, but the more modern style is displayed below:
Changing the way Tk displays notebook tabs will require some modifications to Tk's source code in C--specifically, to call the newer Carbon HITheme API rather than the Appearance Manager. I'll work up some new code to do this, and once it works, I'll submit it to the core Tk developers as a patch. That way, all Tk programs on OS X will benefit from the update.
That's just one example. There are others, but I can only tackle one project at a time.
Learning C is helpful if I ever decide to delve more deeply into Apple's Cocoa frameworks, because the core language of Cocoa--Objective-C--is based on C. However, it's more likely that I will concentrate on using what I learn from C to enhance Tk.
I haven't yet tested my programs on Leopard, but I don't anticipate any major difficulties. I plan to delay upgrading to Leopard for a brief period so I can do one more release of each program--PacketStream, Phynchronicity, and PortAuthority--to smooth out the transition to the new OS. After that point, my efforts will focus on supporting Leopard, and working to ensure that my programs offer the best user experience on that version of the OS. An older, Tiger-compatible version will continue to be available for download for users who do not upgrade to Leopard, but no new work will go into enhancing them.
Fri, 05 Oct 2007
Phynchronicity 2.0 in the works
I'm currently working on a major update to Phynchronicity, my GUI for the Fink Unix software package system. This new release incorporates the GUI overhaul that I previously developed for PortAuthority and PacketStream.
It's taken a bit longer than I expected to get the new update finished. One reason is that this is a larger update than the other programs: I phased in the changes to PortAuthority over two or three releases instead of one, and PacketStream required fewer changes because it's a slightly simpler program. Also, because Phynchronicity is written in Python instead of Tcl, the code libraries I developed to improve the layout of PortAuthority and PacketStream required some adaptation to work with Python--or had to be re-written in Python altogether. Finally, some of the update issues are simply specific to Phynchronicity--for instance, what's the best way to get all the information I want into a display if Fink (the underlying command-line tool that Phynchronicity drives) doesn't provide this data easily?
I'm pleased with the result; what's left to do is testing and updating of the user documentation. I can't wait to get the new release out. In the meantime, here's a preview of the new version:
Branding: "Making Unix Easy on Mac OS X"
One of the things you'll notice at my main website is a new branding emphasis: "Making Unix Easy on Mac OS X." All of the programs I write provide graphical user interfaces to Unix command-line utilities on the Mac. Two of the programs--PortAuthority and Phynchronicity--provide an easy way to manage the installation of Unix software on the Mac, with GUI's for the MacPorts and Fink software packaging systems. The third program, PacketStream, provides a similar interface to the tcpdump network monitor.
All of these command-line tools are powerful and can be easily accessed if you have Unix command-line chops. However, many Mac users who might be interested into tapping into the power of these applications don't necessarily have the command-line knowledge to do so. That's where my applications come in; users are willing to purchase them to tap into the power of the command-line.
For me, this is the real joy of programming on the Mac. It's the combination of the insanely powerful Unix underpinnings and the elegant Aqua interface. This commercial niche simply doesn't exist on any other platform. There are lots of command-line tools on Unix, and a large number of graphical interfaces for them--but Linux users simply don't pay for software. And while Windows users do pay for software, the Windows command-line environment is pretty anemic; there simply isn't much there for a GUI to tap into.
Many Mac developers praise the Mac because of the cool things afforded by the Cocoa programming environment. That's great for them. But I'd also suggest that the Unix foundation of the Mac is a secret weapon for the platform as well; at least, it's where I've found a very fruitful place to work. And I'm only just beginning!
Thu, 23 Aug 2007I've decided to discontinue VuMan, my man page viewer. Like NameFind, which I previously discontinued. VuMan has sold very poorly. It targeted an extremely narrow niche, and had a great deal of free competition. In deciding whether to update its interface or not, I concluded that it would take a great deal of work to add the features I wanted, and the return on that investment would likely be poor.