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
I am now accepting donations to support my open-source work on Liberapay--a funding platform analogous to Patreon, but for open-source developers. If the products I develop or the projects I maintain are helpful to you, please donate to hep fund my time spent on these projects. Thank you.Tue, 21 Aug 2018
My applications are all now priced at $10, reduced from $29.99.
For years I've resisted the race to the bottom that seems to be prevalent in software pricing for the Mac and Windows; my attitude is that "price is an indicator of quality" and I did not want to sell my applications short.
It's hard to ignore the market forever, though, and facts are facts: software is lower in price than it was 10 years ago. Users expect it. An application that retails for $50 today might be a "pro" app that would have cost $100-200 a decade ago.
My apps, being fairly simple utilities, are simply not competitive at a $30 price point in today's market. Hence, the reduced price.
I'm hopeful this will result in a few more sales, as most of my apps do not sell well at the higher price point. But I don't expect to see a huge jump in revenue. Instead, this is just a likely-overdue move to bring my products' price to where the market has judged similar products should be placed.
Another pricing model is becoming increasingly common in software: subscriptions. Apple is apparently pushing developers on its platform to adopt this model wholesale. I have a lot of app subscriptions, mainly for Adobe and Microsoft products, so I'm familiar with this approach from a user perspective. I'm not sure at this point how to implement it in my own apps, or whether this even makes sense for small utilities.
So for now, $10 for an initial purchase is where I am. I have no plans to change my free upgrades for life policy.Sun, 16 Aug 2015
These releases are the result of a two-month change toward looser enforcement of user registration, i.e. paying for a license to keep using the application after a thirty-day demo. I decided to make the releases nagware (they would pop up an alert if no serial number were found) but not otherwise limit their functionality, even after the 30-day demo period ended. The result was striking: without the requirement to pay, no one paid. I've had no sales over the past couple of months even with the usual number of downloads. Reviewing the rather large drop in sales revenue, I recalled this change I made to my registration code and concluded that was likely the cause. As a result, I've re-enabled the stricter registration code, and demos will once again expire after 30 days. Users who have been using the apps for the past couple of months without registering will eventually have to pay for a license if they want to keep using the apps. (You only pay once, by the way! Upgrades are provided free for life.)
Registration code is one of the duller parts of an application--a lot of housekeeping code, and surprisingly complicated, even with a fairly basic registration scheme such as the one I use. In the past my code has been prone to unexpected bugs that caused the code to freeze my application. There are a lot of scenarios a developer has to test for--the existence of a license or not, measuring how long a demo has run, and so on. It's not fun. To be honest, I eliminated the demo period because I wanted to remove the headaches of keeping the code tested and consistent. However, that code provides an essential function--ensuring that customers who continue to use my application actually pay for the work I've done. In fact, it's the most important function my code provides, from a financial perspective, especially now that I'm moving my applications out of the Mac App Store.
It's a bit disappointing that I have to use a stricter registration scheme to ensure that my work provides a bit of revenue, but I guess it's human nature to avoid paying for something if you don't have to. My code doesn't take elaborate measures to enforce registration, but it's strict enough to keep honest users honest, and that allows my apps to provide a bit of financial support for my business and family.Tue, 30 Jun 2015
Now that I've begun that work, I find my heart simply isn't in it.
My heart is with the Mac.
I've done enough work on Windows and Linux to know that I can certainly develop for those platforms, but there's a reason I stay with the Mac--even using a cross-platform toolkit. It is by far the best environment for developers. I absolutely love developing for the Mac, even in spite of Apple's many restrictions, even as I move out of the Mac App Store for good.
If my work on the Mac isn't very rewarding financially, it can at least be rewarding in terms of enjoyment.
Reading Brent Simmons' recent blog entry, "Love," crystallized this for me:
Write the apps you want to write in your free time and out of love for the platform and for those specific apps. Take risks. Make those apps interesting and different. Don't play it safe. If you're not expecting money, you have nothing to lose.
I'll keep open-sourcing key components of my apps, and of course I will continue to do my essential open-source work as maintainer of Tk on the Mac. But I will also continue to do my own commercial work, making what money I can, and making the best apps I can.
You always come back to what you love.Sun, 28 Jun 2015
I am undertaking some fairly significant changes to my apps.
First, I have decided to open-source all my code, while still charging for pre-built binaries. I'm a strong proponent of open source code, and this move has been in the back of my mind for years. I have nothing to hide in my code. Others may find the code, not just the apps, useful. So I am in the process of establishing open-source repositories of all my code at http://fossil.codebykevin.com, using the elegant, superb Fossil source code management tool developed by D. Richard Hipp, author of the hugely popular SQLite database. I am first making available various libraries and packages I use in all of my applications, and then will follow with the source code to the apps themselves.
Second, I will be taking my applications cross-platform whenever it makes sense to do so. I would like my apps to be as widely used as possible, and this means that I would like to get them on more platforms than just the Mac. In practical terms this means I will be re-working the applications' code a bit to account for differences in platforms (Windows and Unix/Linux have different keyboard shortcuts than the Mac, for instance). I expect these differences to be fairly minor. The larger challenge here will be to set up processes for building and deploying the applications on each platform. (I expect to provide pre-built packages for Windows and Mac, but because of the diversity of platforms and deployment systems in the Unix world, I will only provide source code there.)
Third, these changes will require not just some modification of my applications' source code to fit in reasonably on each platform, but a simplification of the code design. In practice, this means removing code that is not essential to the application's functionality, or re-implmenting code in a simpler, more cross-platform way. I have a lot of Mac-specific code in my applications that requires compilation and which provides features that does not exist on other platforms (the Mac's Services API, for instance); I also have complex platform-specific code that can be implemented in a simpler, script-based cross-platform mode (printing files, for instance); I also have platform-specific code that expands functionality already provided by Tcl/Tk's core API's (application scripting) without much benefit. In deciding to keep or abandon native API's, I am going to look at whether the functionality is essential to the app and if it cannot be achieved in a similar way using a simpler approach. If the answer to both questions is yes, then the native functionally will stay. Otherwise, the functionality will be removed or re-implemented.
You may wonder about the business case for open-sourcing my code. Will this allow anyone to download my apps for free without paying for them? Well, in theory, yes; anyone can download and patch my apps for their needs. But building my apps is a non-trivial process--most people are not software developers--and I don't expect that many people are going to be inclined to bang away at the steps needed to patch and build my apps. There is still a huge convenience factor in providing an easy-to-install package from the get-go. Given that I am not currently seeing huge sales on the Mac, the upside to expanding my distribution to other platforms far exceeds the risk I am undertaking by open-sourcing my code.
Concurrent with this change, I plan to phase out my involvement with the Mac App Store. Like many other developers have found, my sales in the app store have dwindled to almost nothing, and the increasing technical restrictions on apps deployed there have simply become too large a headache to deal with. (See this discussion for more detail.) I still plan to remain a paid member of Apple's developer network, because of other benefits it provides (documentation, code-signing certificate, etc.). But I also plan to pursue other platforms as well.Fri, 06 Mar 2015
As this roundup at Michael Tsai's blog shows, an increasing number of Mac and iOS developers are having a hard time making a go of indie development. Even the developers of Vesper, considered the best notes app for the iPhone, have been unable to turn it into anything other than a part-time gig, and this is truly shocking considering the talent behind the app: Brent Simmons, a pioneer of indie Mac developers, who took a full-time gig at Omni; John Gruber, one of the leading Mac bloggers (and who, to be fair, likely doesn't need the income, as his blog generates upwards of $450,000 a year in advertising revenue); and Dave Wiskus, a talented app designer/UI specialist.
One culprit is the iOS and Mac App Store's drive for low app prices. As a result, some developers are raising prices. If lowering prices doesn't move the needle on sales, then raising prices certainly is worth a try. It's one reason I've continued to maintain a $30 price point for my own apps. If demand is relatively constant, then higher prices means more revenue.
Still, one thing that many developers do not seem to have admitted: there simply may not be room in the market for so many indie developers. Even if I concede Gus Mueller's cranky point that maybe my apps just suck, and Michael Tsai's observation that "fake is drawing a bunch of pixels into a plain NSView so that it looks like a text field or toolbar" (and to which I readily plead guilty), I think it's still true that the Mac and iOS app markets have changed in fundamental ways. When Brent Simmons has to take a full-time gig, what does that mean for the rest of us?
In other words, I'm afraid that for many of us, "sustainable software" may be less a strategy than a pipe dream.Wed, 15 Jan 2014 Wed, 18 Dec 2013
I don't hear from customers as much as I used to.
Even a few years ago, when I developed a new app or released an update to an existing app, I'd get a lot of e-mails from customers about it. They might be reporting a bug, requesting help with something that was unclear, or suggesting a new feature. Regardless of the circumstances, the communication, the interaction, was very valuable. It made me feel my apps were useful, and gave me a sense of connection to the folks using them.
I'd also send out announcements of new products to new customers, since I had a large database of customer e-mail addresses; back then I fulfilled serial numbers manually, after getting a notification from Paypal. Occasionally these messages would also include requests for feedback on specific questions. Again, the feedback was enormously useful.
Over the past couple of years that's changed. I still hear from a customer or two when I do a new release, but the volume is far less than it used to be. Most of the time, when I get a confirmation of a customer purchase, I never hear from the customer. (The ones I do hear from today are the ones I've heard from a lot in the past.) And in many cases (i.e. the Mac App Store) I don't know who my customers are at all.
I don't know if this is just a factor of the reduced sales of my apps or the changing landscape of the app market on Mac OS X; probably it's a bit of both. But it's not a development I'm happy about. Connection with customers gives me a real sense of purpose with my apps, and I miss that.Fri, 13 Dec 2013
Today I'm releasing updated versions of my apps and unveiling a redesigned website, in what I feel is the most significant transition for my software business in four years (since my apps were ported to run on Cocoa).
As noted over the past several months, I've been working to modernize the user experience that my apps offer, both in terms of new hardware on the Mac (Retina Display) and their general fit with the Mac platform. These new apps offer a resolution-independent UI, a more muted design, support new features of OS X (fullscreen and sudden termination, among others); they also offer improved performance and other functional enhancements. Their under-the-hood organization has also been simplified to make updates a smoother process.
The website redesign reflects the evolution of the apps toward a cooler, more muted appearance. The website has also been re-tooled a bit under the hood for easier, simpler maintenance and updates.
Of the apps, all six have been released from my website, I've posted announcements of them to Mac download sites, and three are waiting for review at the Mac App Store. (I didn't want to hold up the release of my apps because of Apple's review process; the App Store versions will simply have to come when they come.) One app I had previously decided to discontinue has been revived--NameFind, because I still use it frequently, and because I'm personally fond of it. The other apps I discontinued had little constituency any more, and I had less personal investment in their functionality.
What value does a more muted appearance, better performance, and simpler internal design offer to my customers? For one, it means that my apps provide a smoother working experience with the latest version of OS X than before (even though the apps are somewhat less native overall, trading an NSToolbar for a simpler toolbar layout that can be configured more extensively in my toolkit of choice, Tk). I've made my apps 10.9 only to ensure they support the latest features. It also means that the apps now have a strong foundation for updates; I can focus on refining app features rather than re-architecting and re-designing the apps at a foundational level.
While it's my hope that these apps enjoy better sales, I've been trying for so long to grow my software business only to see its sales gradually decline that I have adjusted my expectations. The Mac software landscape has changed in the past few years; paradoxically, as the user base has grown because of the influx of iOS developers, it has become harder for an indie developer to stand out, to make a living. Over the past year or two I've seen so many talented developers---developers far better than me--throw in the towel on product development and shift over to contracting for other companies. It's not easy. I don't depend on my app sales for my living, so I don't have to make the choice to focus on something else I enjoy less, but I empathize with those who do.
So what's the theme of "reinvention"? It means I've streamlined my app lineup, from one I had planned to grow to a dozen or more apps to a smaller one (six, with possibly one or two more if I can find a specific niche to target). Downsizing my sales expectations, downsizing my app portfolio: these have been my focus this year. Overall my sales are down a bit from last year, and are significantly down from a few years ago. But even as I downsize my app portfolio and watch my sales taper off, the apps themselves are better than ever. I'm proud of them.
The flailing around I've done over the past few years--trying and failing at Windows development, doing a large amount of open-source development, releasing a commercial iPhone app that sold not at all, briefly hanging out a shingle as a software consultant before realizing that working as a software developer for someone other than myself has no appeal whatsoever--has left me where I am now: a Mac developer who earns some revenue from Mac apps, and an iPhone/mobile developer who targets the platform for branding/strategic reasons (my publishing business) rather than as a revenue stream. In both cases I am producing quality work, better than I ever have, even as the money has declined. 2013 was the year I spent coming to terms with this paradox, and it will guide me into 2014 and beyond.Fri, 08 Nov 2013
After my recent discussion of finding the right mass of customers, and given the ambitious task I've set of doing major updates of all my apps, I've also taken on another difficult task: deciding how many apps to move forward with.
I have one steadily-selling app (PortAuthority), and several others that sell in volumes ranging from modest to non-existent. PortAuthority is not far enough ahead of the rest to sustain my software business by itself; instead, it accounts for about half my sales overall, while a cluster of my other apps accounts for the other half. Of that cluster, several apps show up in modest numbers individually, and some contribute only a sale or two per year.
I've been very reluctant to decide to drop any of my apps, since I've invested a good deal of effort into each of them, and all solve problems I've had at one time or another. However, the scale of the app updates I'm undertaking is rather large, and I simply don't have time to invest in that level of work for an individual app that isn't selling. So, today I took a hard look at sales numbers, and have decided to drop three apps from my lineup: my file renaming app FileMorph; my file search app NameFind; and my UI for Fink, Phynchronicity.
None of these apps have sold more than a couple of licenses per year over the last few years. Phynchronicity got some nice attention when it was first released in 2007, and was a solid seller for a few years. But its sales in recent years have dropped to near zero. By contrast, NameFind and FileMorph never took off at all and only registered sales when accompanied by heavy promotion and discounting. All three apps are in crowded markets with a major incumbent or lots of competition, and it was just hard for them to get any sustained tractions. (By contrast, PortAuthority is the major established incumbent in its market niche, and no other competitor has been able to gain traction.)
Somewhat to my surprise, other apps such as QuickWho and TextSweep have found modest, but steady, sales on the Mac App Store. These apps, along with Manpower, are not stellar performers individually, but each contributes to an average monthly sales total that is about equal to PortAuthority. In contrast to the apps I'm dropping, these apps are in more focused niches and don't seem to have a lot of competition; for a small but sufficiently large number of users, these apps fulfill a need. Apps of this kind also really benefit from being in the Mac App Store; while the App Store is crowded, it offers such a huge potential market of Mac users that it's easier to reach the small number of users who might be interested in my apps.
Reviewing my sales numbers and deciding to drop some slow sellers accomplishes two things for me. One, it will allow me to better focus my efforts. It's easier to update five apps than eight, especially when one of the apps, Phynchronicity, would require significantly more time to update than the rest. Second, this review pretty much answers the question I posed previously: I'm having more success targeting narrow niches, where there isn't much competition, rather than large niches. This also means that any new apps I develop will be geared to smaller niches rather than large ones, and will focus on being included in the Mac App Store. Except for PortAuthority, my non-Mac-App-Store sales are pretty negligible. (PacketStream, my Mac network monitor, cannot be in the Mac App Store, and its sales numbers just made the cut--but it sells far less than PortAuthority.)
This has been a useful and productive process. I'll be able to finish updating my remaining apps fairly quickly, and I'll be able to do incremental updates much more frequently with a smaller number of apps; this has been a real challenge for me in recent years. And I'll be very careful before deciding to add any new apps, as well.