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.

No more user forums

I've removed the user forums from my website, as they were becoming overrun with spam and with few postings from customers in months. This doesn't mean I am uncommitted to providing support; simply e-mail me at kw@codebykevin.com and I will respond to your inquiry in a prompt fashion. Thanks for your understanding.

[/business] permanent link

Closing Windows

I've decommissioned my Windows software site. After three months, the Windows version of QuickWho had failed to register a single sale. While QuickWho does not sell in huge volume on the Mac, it does sell a bit, and I expected similar performance from Windows.

Some might say that I didn't give Windows enough time--I released QuickWho for Windows at the end of the summer--but I am not entirely a rookie when it comes to developing software, nor to marketing it. I tried everything I knew to gain some attention for QuickWho, and it gained next to no attention at all. Even a few sales would have persuaded me this investment of effort and time was worth it, but they were not forthcoming.

I do not intend to give up on pursuing growth in my sales and my product portfolio, but my experience with Windows has persuaded me that my time is better spent on the Mac. I'm also going to be investigating opportunities in a related platform developed by Apple. More on that later.

[/business] permanent link

Playing in the sandbox

Apple has pushed back its deadline for applications to comply with Lion's sandboxing requirements, which is coming soon as a prerequisite for new submissions to the Mac App Store, to March 1, 2012. As I've explained before, sandboxing is a big new development for OS X. Briefly explained, it places strong restrictions on what an application is able to do in terms of reading and writing data, network access, and so on. A developer must assign specific privileges, or "entitlements," to the application. The intent is greater security for end users, by making it harder for malware to take over an application and hijack the user's system.

Like many developers, I have some concerns about the entire way sandboxing is being rolled out. Unlike many other major changes from Apple over the year, sandboxing is being introduced without much evidence of internal testing by Apple. Developers are being asked to be guinea pigs as Apple works out the system-level kinks in the sandboxing system. This in turn creates a lot of uncertainty among developers about what will and won't work with sandboxing, what changes developers will have to make to their applications to conform to the sandboxing model, and indeed, whether it's worth it to continue selling applications in the App Store if sandboxing would significantly change the applications' feature set.

In my case, I've had to hold off on submitting a sandboxed version of QuickWho to the App Store, because there is a mysterious crash in the application that is a direct result of sandboxing. It does not appear to be something I can fix, so I've had to submit a bug report to Apple and hope that it gets reviewed and addressed in a timely fashion. That's a form of uncertainty I'd rather not have.

I don't anticipate giving up on the App Store, but I'm going to have to continue to monitor the situation with sandboxing and adapt as best I'm able.

[/business] permanent link

Windows

While I've been quiet lately, I haven't been idle. In fact, if you want to see what I've been up to, visit Windows Software by WordTech--my venture into the world of Windows desktop software. For more details on why I'm doing this, see my blog entry. Hoping it works out!

[/business] permanent link

Expanding the portfolio

With today's release of Phynchronicity and PacketStream, I have now completed a major cycle of updates and modernization of my existing products. Now all my current products have significantly improved look and feel. Of all the work I've done over the past couple of years on platform-specific integration with Tk, my Cocoa toolbar wrappers (mactoolbar and prefstoolbar) are the most important from a visual standpoint.

Just as importantly, all six of my current products are at a good level of maturity; they have been through several releases each, and are relatively feature complete. This does not mean they have no room for improvement or additional features, but all six do what they set out to do, and do it well; none has a glaring hole in its functionality.

Now: it's time to expand the portfolio.

I've drawn up a list of approximately nine products that I will be working on over the next year or so. When all is said and done, I should have approximately 15 applications in commercial release, with varying degrees of active development.

My reason for undertaking this project: I want to grow my sales. And because my existing products sell modestly, the only way to increase my sales volume is to increase the number of products I have to sell. The strategy is simple: more products at modest volume = higher sales = more revenue.

This is something I have wanted to pursue for a long time, but there were several obstacles. First, my existing products needed continued development and maintenance. Second, I was doing a great deal of work on building up my development platform--creating libraries and components that could be used in any program I developed. Third, external market conditions--specifically the Mac App Store--forced me to re-tool both my products and my development process to meet App Store requirements.

None of this was wasted work. I continue to believe that Tk-Cocoa is the best cross-platform toolkit for the Mac. I'm backing that up by becoming one of the maintainers of Tk on OS X. And I'm an active participant in the Mac App Store. But if all that time spent working on libraries and Tk's core and my own App Store development process is like planting seeds, it's now time to bring home the harvest by incorporating that work into more products that I can sell.

As a result, while I will continue to work on Tk-Mac's core, I'm done creating libraries and extension packages for the near and middle future, and I'm not going to be substantially updating my existing apps for a period of some months. Instead, I'm going to be proceeding full steam ahead with development of new applications, trying to increase the number of modest sellers in my portfolio to the level where those modest sales add up to real volume.

This is not an easy strategy to follow. The usual advice in the Mac development community is "make your apps awesome"--as this tweet from Gus Mueller of Flying Meat Software, responding to some of my own thinking-out-loud of this problem on Twitter, demonstrates. Well, the issue here is that I've tried to do this. My applications are orders of magnitude better than they were four or five years ago. I'm also much smarter about marketing, about getting the word out on my products, and taking advantage of promotional opportunities (app bundles, one-day discounts, etc.) to increase sales. But product excellence and good marketing aren't enough. For whatever reason--because of luck, competition, the product niches I've chosen, or, perhaps because I have failed to "take out the suck"--my apps sell modestly, some less than a thousand dollars per year each.

As a result, a realistic assessment of the best path to growth requires me to recognize that I don't have a breakout product--and probably never well. I have a portfolio of modest sellers. There are two ways to increase my sales volume: sell more of what I've got, or make more to sell. I can't seem to sell a lot more of what I've got. So I need to make more products to sell.

There's a name for this strategy: the "long tail," first coined by Chris Anderson in an article in Wired. It's a strategy optimized for the Internet and online selling, in which a huge number of niche products, selling little in themselves, achieve massive scale in toto. Amazon is built on this strategy. So is iTunes. Another business I'm involved in, a publishing operation that utilizes print-on-demand technology to sell small numbers of many, many books, also makes use of this strategy.

So I'm confident the strategy is sound. The challenge will be execution. Software development is a labor-intensive process, and creating good applications is a non-trivial enterprise. My approach here will be to lean as much as possible on projects I've already done or can access--open-source libraries and tools--to do a lot of the work for me. Speed of development and release is a major criterion in selecting which products to do and which products to reject. But my approach isn't totally cold-blooded: I'm only going to work on things I'm excited about, that I will make use of, that will scratch some personal itch of mine. That's always been a rule of thumb: I believe that if a product I develop serves some need of mine, then at least a few other users will probably feel the same way.

I'm very excited about this new path I've chosen. I've been wanting to develop some new products for a long time, and I've finally arrived at the point where I'm able to do so. If nothing else, this will be fun, and I'm also hopeful that it will improve my bottom line in a significant way.

Wish me luck!

[/business] permanent link

PortAuthority *not* in Mac App Store

One additional note about PortAuthority: it is not available in the Mac App Store, nor will it be in the future. PortAuthority runs afoul of several App Store guidelines, specifically in requiring an administrator password to run most functions, and also requiring an installation of MacPorts to function at all.

PortAuthority's sales have not suffered to date because it is not in the Mac App Store, and I hope that continues to be the case. I am grateful for the opportunity provided by the App Store, but I don't believe it should be the only avenue available for installing software on OS X. That limits user choice, and not just by restricting the channels the can use to purchase software; it also would limit the kind of software, indeed the kind of things, one can do with one's computer.

[/business] permanent link

Finally: Immediate serial fultillment

Since a few of my apps have been accepted (and are selling) in the Mac App Store, I've taken another look at how I handle sales and fulfillment for my non-App Store products. When viewed against how simple and quick the App Store fulfillment process is, my long-standing practice of using Paypal for payment processing and sending serial numbers manually no longer makes as much sense.

After doing some research, I've settled on a new service provider for payment processing and license fulfillment for my non-App Store sales: BMT Micro. BMT Micro is a respected provider among independent developers; they come highly recommended, based on the comments I've seen. Their website is extremely easy to use, much easier than some of the other providers I reviewed. Just as importantly, they also promise to be very friendly and easy for my customers to use for payment processing, accepting payments in almost any currency and with almost any method (credit card, Paypal, wire transfer, etc.).

Finally, BMT promises to improve a long-standing weakness of my customer service: serials will be sent out immediately rather than waiting until my company can manually reply to an e-mail. This policy may have made sense in the past, but the App Store has forced developers to raise the bar in all aspects of their business, and immediate fulfillment of serial numbers is a necessary step.

PayPal is an outstanding company, and I will continue to use them for numerous aspects of my business (custom billing, etc.). However, utilizing them for automated serial fulfillment added a lot of complexity to the process (it requires a lot of Web programming, and I am not a web developer), so moving to a different provider that handles all of that for me--at reasonable rates--is a good decision here.

[/business] permanent link

60% off NameFind on 3/1

I'm participating in a promotion for NameFind next Tuesday, March 1, on Bits du Jour, a software promotion site. Bits du Jour is well-known as a Windows software promotion site, but they are expanding their coverage of the Mac, and asked me to participate. Next Tuesday you'll be able to purchase a license for NameFind for just $10, 60% off the regular price. Here's the link to check it out:

http://www.bitsdujour.com/software/namefind/

[/business] permanent link

The waiting is the hardest part

I first submitted NameFind to the Mac App Store on December 5. It's been rejected twice, for crashing on startup, and for accessing private functions in some Mac-specific frameworks (specifically, Tk-Cocoa, which I bundle with my apps, accesses a number of private Cocoa functions, at a low level). Both crashing and use of private API's run afoul of Apple's guidelines for the App Store. I've since tweaked NameFind yet again and resubmitted the app, in hopes that it works this time.

I realize patience is a virtue, but I am growing quite frustrated with the process of submitting my apps. None of the numerous revisions I've made to NameFind as part of the App Store submission process have improved the application. Most of the changes are simply revisions of the way I build and deploy the application--a lot of behind-the-scenes work with no visible change to the user, simply trying to avoid mysterious crashes that don't show up on my own system.

Worse, some of the changes I've made are what developers call "regressions"--rolling back some features to older, less robust versions. In the case of NameFind, I've replaced the bundled Tcl/Tk frameworks I customarily and link the program directly to the Tcl/Tk frameworks installed with OS X--some of my research suggests that while the system frameworks access the same private API's as the frameworks I bundle, it's kosher for Apple's system frameworks to do so because, well, they're installed by Apple. Unfortunately, the version of Tk-Cocoa that's installed by Apple is immature (c. May 2009), with a lot of bugs and some missing functionality. This means I can't take advantage of some of the improvements I've contributed to Tk in the past year or so, including modernizing the display of notebook tabs and implementing a unified-style toolbar.

Just as frustrating for me is putting my software business on Apple's timetable, rather than my own. The App Store submission process is slow, opaque, and bureaucratic. As an independent developer, I thrive on rapid, nimble development, but things have more or less ground to a halt as I submit my app, wait weeks, and then try again. This brings to mind Joel Spolsky's notion of fire and motion. I'm pinned down by enemy fire, rather than inching forward a little bit, day by day.

Having come this far, I'll let my current submission of NameFind run its course. The potential upside--increased sales--looks promising. But unlike the iPhone/iPad app ecosystem, the Mac App Store is not the only game in town. Patience is a virtue, but my patience is not infinite. And if NameFind is rejected yet again, I'm not going to stand still. Like Rogue Amoeba, I'll keep my focus outside the App Store, and hopefully thrive and innovate--without waiting.

[/business] permanent link

Update on the App Store

A quick update on the App Store: submitting my apps is proving to be more difficult than I expected. I've had an app rejected twice for technical reasons, and figuring out how to proceed is complicated. Nonetheless, I'm going to persist, and eventually have the majority of my apps in the App Store.

[/business] permanent link