| Code by Kevin | |||||
|
Subscribe to RSS Feed 2010 2009 2008 2007 2006 Categories Business Software General |
home :: business
Wed, 24 Feb 2010 Readers of this blog will notice that I've lowered prices on two of my products recently. You should not, however, assume that I'm going to lower prices across the board as I release new products. In the past I've tended to charge the same prices for all of my programs; once I set a price point for one product, the rest went to that price point as well. But I've found this actually isn't the smartest way to set prices, since it's more rooted in a desire to be consistent than in finding the right pricing balance between my product and the market. Some products, of course, are selling quite well at their current price point, and I see no reason to lower those particular prices.
I've added a user forum section to the Code by Kevin website. This is a place for users of my products to post questions and suggestions about these products, the website, and other related subjects. I hope that users of my software will find the forum site a useful resource.
The forum is here: http://www.codebykevin.com/forum/. Enjoy.
The perfect is the enemy of revenue
Even though I've made a great deal of progress over the past year in enhancing the native integration of my programs on the Mac, I'm not entirely satisfied. My programs can now support text and files dragged to them, but you can't drag text from them to other applications. They can now be called from AppleScript, and they support the Services menu, but you can't access the Services menu from within my programs. And while my programs can now print with nice, "sheet"-style dialogs, they don't print using Cocoa API's.
The question before me: is it better to release software that doesn't support these nice features in their entirety, or would it have been better for me to wait until the features worked perfectly?
This is a actually a dilemma that all software developers wrestle with. Marissa Mayer, Google's vice president of search and user experience, favors an incremental release process and continuous improvement. Apple, by contrast, favors "insanely great" products that are little gems of perfection. Many indie developers in the Mac community tend to embrace the Apple view of things. In the words of Brent Simmons, "You make beautiful hardware and software--you create an experience so new and compelling that people lust for these things."
In practice, and also in philosophy, I tend to come down more on the other side--releasing even if it ain't perfect. This doesn't mean I ship programs that fail to work as advertised, that are glaringly buggy, or that lack any useful features. Some proponents of "release early, release often" see no problem with releasing stuff that crashes--hey, it's a chance to identify bugs!
However, I do embrace Voltaire's maxim that "the perfect is the enemy of the good." In software terms, this translates to, "the perfect is the enemy of the released product." There's no opportunity for a perfect product to make money if it's not in released form. In terms of my products, this means that I'd rather partially implement the easy part of a useful feature than delay release indefinitely for a complete, perfect implementation.
This has been my approach with drag-and-drop, AppleScript support, Services, and printing. The parts that I implemented were the relatively easy parts--and even those aren't easy. Drag-and-drop took several weeks, and a good deal of collaboration with the original creator of the TkDND extension, to implement dragging to a Tk window. Dragging text out of a Tk window is much, much harder because of technical conflicts between Tk and the underlying Cocoa foundation. I had no idea how long it might take to work through these conflicts, or even if I had the skill to do so. So I decided to move ahead with what I had.
AppleScript support is another incomplete, difficult feature to implement. My Python programs actually have the hooks in place to provide extensive AppleScript support--implementing AppleScript commands that other applications can call--through the excellent appscript Python library. However, my Tcl applications can't provide the same level of support because the standard Tcl library for AppleScript support, TclAE, will need an extensive rewrite to support 64-bit--a rewrite I currently lack the skills to undertake. Instead, if I want to offer AppleScript support, I'll have to use Tcl's built-in "do script" AppleScript command--which means I'll have to implement raw Tcl commands that other applications can call via AppleScript. Functional, but hardly perfect.
Services is yet another feature where the implementation isn't as perfect as I'd like. For technical reasons similar to the issues with drag-and-drop, my Tcl and Python programs can't access the Services menu from within the application itself. And they can only export Services functionality because I discovered a handy tool called ThisService, which allows you to create Services from scripting languages. I'm using the AppleScript support my programs are implementing to add the Services functionality as well. (I tried to create a Cocoa extension that would hook into the Mac's Services functionality, but was not successful--again, technical conflicts between Cocoa and Tcl that I could not work through.) While I feel my solution using the ThisService tool and AppleScript was elegant and actually quite clever, it's certainly not perfect.
Finally, printing. It would be nice to support native printing. Yet the Mac's built-in command-line interface to printing is so adequate for my needs that it's hard to muster too much worry about the lack of Cocoa-native printing in my programs.
My thinking about these issues is guided by more than just my desire to earn revenue by shipping products. It's also guided by the Unix philosophy of programming, which I've written about before. The key idea I'm taking away from the Unix philosophy is "keep it simple, stupid." If I can adequately implement a feature that is effective if imperfect, it's better to go that route than wait indefinitely for perfection. It's hard to say, at this point, if I'll ever perfectly implement drag-and-drop, AppleScript, Services, or printing in my programs. In 2010, my goal is to release commercial products, not open-source libraries. That means building on what I have; it's good enough. Waiting for perfection means waiting for revenue.
Postmortem on 2009, and looking forward in 2010
At the end of 2008, I posted a blog entry on what I learned that year. I didn't have time to do anything similar at the end of 2009, so I'm carrying it over into 2010. Which is appropriate, given that I am now more interested in looking forward than looking back.
2009 was mostly a transitional year, in which most of the lessons of 2008 provided irrelevant. In 2008 I talked a lot about the importance of marketing. Regardless of my marketing strategy, the Great Recession kept sales down, down, down. I also complained about the difficulty of learning Cocoa and swore I'd never do it. But most of my technological work in 2009 was spent in learning various aspects of Cocoa and applying it to Tk, which itself was ported to Cocoa by Daniel Steffen. And finally, I said I'd add a lot of new products; instead I revived one I previously discontinued, and released incremental updates of everything else. (The single biggest upgrade of all my apps was moving them from Tk-Carbon to Tk-Cocoa and 64-bit capability, as well as UI freshening.)
I now enter 2010 a much stronger developer than I was a year ago: I can delve into lower-level technologies when necessary (Cocoa), while still taking advantage of the rapid development features of my primary programming languages. My toolbox is much richer than it was a year ago, and with drag-and-drop, native icons, custom dock icons, sheet windows, and AppleScript and Services support, my programs will be much better Mac citizens: these are real improvements in usability, functionality, and the user experience.
Now that I've greatly broadened my development skills, however, it's now time to begin applying it to my programs in a substantial way. The first task, of course, is to integrate these new features into my programs in appropriate ways. The next task is to explore opportunities for new applications, opportunities that my new skills now make available. I have lots of ideas, and lots of interests: the challenge will be to translate those ideas into products that users find compelling enough to pay for.
I want to improve my sales in 2010 as much as I improved my development skills in 20009. I think I'm finally in a position to do that. Sales really surged in the last two months of 2009, to the point where sales finished at the same level as 2008--a pleasant surprise, given how slowly the year started. There's still a lot of room for improvement, but like a last-place football team that wins its last four games, I've gained some momentum. I attribute the sales spike to moving my applications to Cocoa: some of the user feedback I've gotten suggests this has made a big difference.
As far as marketing, my product mix, and pricing, I've gathered some data about what works and what doesn't, and will keep working on that as the year goes on.
Bottom line: despite the difficulties of the past year, I feel more optimistic about my software business than ever before. I'll be working hard to bring cool and useful products to the table in 2010.
After launching Cocoa-based versions of all my applications last week, my server was hammered by download traffic. This was the largest release I'd ever done, and the download size of all the applications was larger than before (a consequence of adding universal 64-bit support). As a result, I received numerous complaints about slow downloads or, worse, inaccessible downloads.
Too much traffic is a good problem to have, but paradoxically, there's a danger that I might lose customers. To quote Yogi Berra on a fashionable restaurant: "Nobody goes there anymore. It's too crowded."
That problem has been solved by moving my download links to Amazon S3, a cloud-based Internet storage service managed by Amazon. S3 is an inexpensive solution for Internet-based storage and downloads, and other Mac indie developers have recommended it highly.
As a result, traffic on my server is back to normal, and downloads should proceed at a snappier pace. If you've been trying to download one of my apps but found it impossible, try again--you won't be disappointed.
I'm a great admirer of Gus Mueller, the main developer at Flying Meat Software. He's one of
the leading indie Mac developers out there: his desktop wiki VoodooPad and his image
editor Acorn are leaders
in their categories. A few years ago he posted
a blog entry that outlined his path to indie
success, and it has served as an inspiration for many indie Mac
developers, myself included.
Given my admiration for him, I was a bit taken aback by the
curmudgeonly tone of his latest blog entry.
A bit of context: Gus's blog entry is based in turn on an Inc. article by Joel Spolsky of Fog Creek Software about how his software company took
off: founded right at the moment of the dot-com crash of 2000, Fog
Creek struggled financially, laid off employees, found some unexpected
success with its bug tracking product FogBugz, tried all sorts of
marketing gimmicks to improve sales, then finally settled in to simply
improving the product itself, after which sales took off.
There's wisdom here. All the marketing glitz in the world won't
help if your product is terrible, or doesn't meet user needs.
Marketing helps, but it isn't a substitute for having a great product
to sell.
Gus notes that his experience has been similar: improving his own
products has been the biggest factor in the growth of his business.
And he suggests that if other indie developers aren't succeeding, they
should take a look at their own products:
Learn to be your best critic, and you'll learn to ship software
that's worth paying for. If no one is buying your app then you've
either got a dud and you need to focus on something else, or you need
to improve your app so it's worth paying for. And some apps, no matter
how flashy or awesome or genuinely useful, will never make money.
His assumptions here are bit surprising: that if someone's
application isn't selling, it must be because they aren't self-critical enough. That might be true; the developer might be
impervious
to feedback, and even have a reputation for being hostile to user
input. But it might also be that the product is in a highly
competitive market niche. It might also be that there's little demand
for the product. It might also be that the product is in the wrong
place at the wrong time.
Business success is an inexact process. Quite simply, it's a
gamble. If you look at some of Joel Spolsky's other articles, you'll
see that luck played a big role in his success. One of his products,
FogBugz, took off; another one, CityDesk, did not. Although Gus notes
that "some apps...will never make money," I think he underestimates
how much luck plays a role.
Applying these lessons to my own software business, I reach the
following conclusions:
Having said this, taking Gus's advice and serving as my own toughest
critic, I also have to acknowledge: my apps don't sell as much as I'd
like. I'm not a full-time indie developer, like Gus. And (bad) luck
isn't solely to blame here.
Or, to pose the question, "Why don't my apps sell," I could
paraphrase Gus: "Maybe they just suck?"
Well, some people seem to think so. NameFind got a harsh
reception at MacZot the other day; at least one user disparaged my
professionalism as well as noting specific criticisms of the app
itself. (Even amid all the flaming, I extracted at least two
suggestions that I will use for further improvement of NameFind, so thanks.)
Most of that user's complaints stem from the fact that NameFind isn't
written in Objective-C and Interface Builder; it doesn't hook very
deeply into Cocoa. (Parts of it do, but not the whole thing.) That's an
unavoidable limitation of my software since I don't develop directly in
Cocoa but rather with a toolkit that uses Cocoa for basic UI elements
that it organizes using its own API. I have to take my lumps there with
whatever "suck" factor might apply. (Some users care more about this
than others.)
So I concede a certain amount of lost sales because Cocoa's not part
of the equation. I don't believe that's the totality of it, however.
Some of my products target niches with established competitors. I
probably don't market as much as I should. And, at the end of the day,
not every product is going to take off. (Gus himself has discontinued
one or two slow sellers over the years.) Bottom line, it's darn hard to
be a success as an indie developer. For every established indie Cocoa
developer like Gus, there are probably a dozen indie Cocoa developers
whose businesses haven't taken off, for whatever reason. I'll bet
dollars-to-donuts that most of those developers are tough self-critics,
strive to create the best products possible, and provide user support
to the best of their ability. (In short, there are probably more Cocoa
developers whose business looks like mine than those whose business
looks like Gus's.)
Getting back to the title of this blog entry: I think my priorities
are in the right place. It's no guarantee of anything.
I've done a bit more tweaking to the Code by Kevin website, and now I'd like to highlight those changes:
Adopted a "Coverflow"-style effect called Protoflow, developed by Deensoft. This provides a more striking home page than the older, table-styled layout did, and will grow to accommodate the additional products I'm developing. One user complained this was an example of "mystery meat navigation," meaning that it wasn't immediately clear how to navigate to the product pages on the site. Fair enough, so I added a note explaining how to navigate--slide to the right product, then click on it. There are other coverflow-style Javascript packages out there, including ones that more closely mimic the Coverflow effect in Mac OS X, but Protoflow is the only one I've found that allows an image to have an HTML link on it. So, I'm sticking with Protoflow. Adding "A division of WordTech Communications LLC" to the site to make its corporate structure more clear. When you click on a "Buy Now" link on my product page, you are brought to a Paypal page that says WordTech Communications LLC, and a couple of users told me that was confusing. WordTech is the corporate structure I have set up for self-employment, and it pre-dates my work with software, so that's why I am using it. (WordTech is also active in the publishing industry, a business activity that isn't directly related to software, so I don't emphasize the WordTech "brand" in my software activities.) Sharpening the GUI vs. command-line brand message of the site. Apart from tightening up my product copy to focus on this contrast (which I also hope improves my Google traffic), I also added screenshots that show how my programs' data looks in the command-line, and in the GUI I design. I think a picture's worth a thousand words here. Using a different service for the "recent news" box on my site pages, which pipes in the RSS feed from this blog into the main site. The previous service I used has grown very slow and is offline much of the time, which gave me concern for its future. I'm now using rss2html, which is lightweight and speedy. The point of linking the blog feed to the main site pages is to show that there's a lot of activity with my software development. Nothing stagnating here. After all these changes, I've pleased with the new look and usability of the site. Now it's back to product development, incorporating the latest and greatest from Tk-Cocoa. I'm just waiting for a few more bug fixes and patches to go into TK-Cocoa in the next couple of weeks, and then Tk-Cocoa will move from the "development" branch of Tcl/Tk to the main line of the codebase. At that point, I'll be able to quickly get out a few new products, and I'll also post a detailed blog entry about the improvements that Tk-Cocoa is allowing for my software.
After getting some feedback on the Code by Kevin website at the Joel on Software business fourm, I've made some pretty significant changes to the site's design. I hope it's simpler and easier to navigate. I welcome any feedback!
A bug report from a prospective customer about one of my products crashing on Mac OS X 10.4 has led me to this discovery: during the last round of updates, I added a feature (calling a specific command-line program) that isn't supported on Tiger, and is causing the crash. This presents a dilemma: do I update the programs to fix the bug so they continue to run on Tiger/10.4, or do I simply leave it alone and not support Tiger anymore?
With the release of Mac OS X 10.6, a.k.a Snow Leopard, likely coming in the next few months, my solution is to drop Tiger support altogether. This decision is driven by the fact that Leopard (10.5) will soon become the "older" supported version of Mac OS X (Apple typically provides security updates and patches, but no new development, for the immediately preceding version of the operating system). It's also driven by the fact that the minimum supported platform for Tk-Cocoa is 10.5, which is becoming the basis for all my development, and 10.4 support will be going away in any event.
Thus, PortAuthority, Phynchronicity, and PacketStream are no longer supported on Tiger, effective immediately. The next versions of my other products will also not run on Tiger.
I'm sorry for any inconvenience this may cause to users of my existing products; feel free me to contact me by e-mail if you have concerns.
With today's release of PortAuthority 2.7, I have now completed updates for every one of my applications. While each product update included items specific to that application, I also focused on adding a common core of features:
An integrated help viewer. This replaces online help (accessed from my website) and the quirky built-in OS X help viewer. Printing. I want users to be able to save data from my applications to a file, and also to print directly from my applications. The "save/export" functionality has been around for a while, but the printing has not. An improved graphics engine. Specifically, this is an image display and manipulation library called TkCximage, which is part of aMSN, a Tcl/Tk-based client for Hotmail. TkCximage displays almost any image format, and includes on-the-fly resizing of images, which is useful for the help viewer and other products I have under development. I'm hopeful that these features make all of my applications a bit more pleasant and easy-to-use.
With the integration of these features into my current product line basically complete, I'm also going to be focusing in the coming months mostly on development of new products. As I've discussed previously, I have a lot of ideas, and I'm eager to get started on expanding my product portfolio.
|
||||