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
About 18 months ago I posted a blog entry about what I learned in my first year of indie commercial Mac development. Now, at the end of 2008, I'd like to share more about what I've learned over this past calendar year.
There's little doubt this year has been a challenge for me. 2008 sales came in lower than 2007 sales. I attribute this to increased competition for my best-selling app, and also to the lousy economy. Still, even with these difficulties, I've worked on laying the foundation for growth in the future.
Here are some of the new components of my growth strategy:
Focus on a single technology platform. The amount of time I spent over the past 18 months trying to learn Apple's Cocoa frameworks has been enormously destructive to my software business. Simply put, instead of developing new products or updating existing ones, I was wasting time doing finger exercises in a programming environment I neither understood nor enjoyed. Never again. My chosen techonologies--Tcl/Tk, Python, and AppleScript--are not perfect, but they provide everything I need to develop Mac applications. Any new technologies that I add to my toolset, such as possibly Ruby, will be chosen because they complement the platform I've already assembled.
Marketing, marketing, marketing. My marketing efforts in the past consisted mainly of posting my apps at Mac download sites, sending out a news release (when I remembered to do so), posting announcements on this blog, and sending out e-mail announcements (when appropriate). My marketing efforts were, to put it mildly, haphazard. Over the past few months, I've made a serious effort to upgrade my marketing efforts. I've assembled a mailing list of registered users of my programs, and I send special announcements and promotions to this mailing list. This has definitely helped give sales a shot in the arm. I'm also trying to upgrade the new releases I do, using a paid PR service to increase the visiblity of my releases. The jury is still out on my PR strategy, but it's definitely worth some experimentation.
Keeping prices at a sustainable level. One of the most alarming aspects of the mad stampede of Cocoa developers to the iPhone has been a race to the bottom for pricing. 99 cents is the benchmark price for iPhone apps, it seems. How many developers can earn a living by putting their products on the "dollar menu"? A few, maybe, who have a bestselling hit, but most won't be able to manage. In my case, my apps have increased in price from free to $5 to $15 to $20 to $25. I work hard on my programs, and I want to charge a price that will allow me to sustain their development. I did notice a slight decline in sales when prices went from $20 to $25, but I have decided not to lower prices. Keeping the prices a bit higher gives me more flexibility to offer promotional discounts that still will bring in some decent revenue: that has worked very well for me this year with "preferred customers" (those on my mailing list). Diversifying my product offerings should, over the longer term, increase my sales revenue as well.
Focus on a specific market niche. I've chosen to focus on providing applications that leverage the Unix underpinnings of Mac OS X. As I've written before, this niche forecloses some application options (such as iPhone apps), but it does give me a pretty wide area to cover: I have no shortage of application ideas. I will continue to develop new applications with my market niche in mind.
Continue to upgrade existing and enhance applications. Even as my best-selling application, PortAuthority, slowed down a bit because of increased competition, other applications saw modest-to-impressive sales increases this year because I kept updating their capablities. In some cases these were application-specific upgrades, such as adding PDF export to Manpower; in other cases these were across-the-board enhancements, such as a new help viewer, imaging engine, and printing library, that can be folded into all my programs and improve their usability. I've also tried to improve the first impression that users get from my software by moving from a plain download disk to one that uses a fancy background, with a link to the /Applications directory for easier installation.
Diversify my product portfolio. At this time last year I had three products for sale--PortAuthority, Phynchronicity, and PacketStream. In 2008, I added Manpower and QuickWho. Manpower has proven to be a good seller; as a 1.0 product without a lot of features, QuickWho is moving slowly, but it has sold a bit, and I am confident that its sales will grow as I continue to add to its capabilities. And in the coming year, I will continue to add new products. In fact, I am planning to move into a period where all I am doing is new product development. That may cost some sales over the short term, but as these new products mature and find their place in the market, I believe that sales revenue will steadily rise.
Leverage open-source wherever possible. Although my programs are proprietary, or closed-source, they make heavy use of open-source components, from icons, to graphics libraries, to the very languages they are written in. Using open-source components allows me to spend less time implementing low-level functionality in my programs and allows me to spend more time on what is unique in my applications. Use of open-source also reduces both my financial overhead, because I do not have to pay for such services as icon desgin, and my time overhead, because I can do more rapid development and frequent releases. I do not steal open-source componeents in violation of their license, either; I use components that are compatible with proprietary code. In the spirit of giving back, I also maintain my own open-source libraries, which others may download and use freely in their software.
Take the long view. I've said this again and again, but it's important to take the long view in running any business. Most businesses are not overnight successes. This year has been something of a disappointment from a sales standpoint, but definitely not from the learning standpoint. I feel I have laid a very strong foundation for steady growth in the future, and taking the long-term view will allow me to achieve that growth.
As John Gruber has noted, "The full story is that like most forms of popularity, software sales tend to follow a power-law distribution. Most apps languish in obscurity, but popular apps tend to become super-popular." My apps are not super-popular, and I do not expect them to become so, but effective marketing and continued improvement can help to lift them out of complete obscurity. And, given a sufficiently large product portfolio, modest individual sales can achieve good revenue in the aggregate. This strategy is where my experiences in 2008 have led me. My challenge, in 2009 and beyond, is to execute.Mon, 01 Dec 2008
I've released version 1.0 of QuickWho, a GUI for the Unix command-line "whois" tool. QuickWho locates information about the ownership and registration of Internet domains, using whois as its underlying engine.
There are already many ways to access whois data, including from the command-line, from Internet sites, and even with other GUI tools on the Mac (some free and some shareware). I wasn't satisfied with any of them, however. I wanted something quick and simple that I could simply launch, type the domain name, and get the data I was looking for. So QuickWho came into being.
Version 1.0 of QuickWho has a small set of features; its main focus is on providing a simple way to get whois data. I plan to add features in future releases to make it more than a simple GUI wrapper for a command-line tool. If you run a lot of whois queries and want a nice, simple tool to make it easier, QuickWho might fit the bill for you.Sun, 16 Nov 2008
It does more, that's why.
Someone posted a review of Manpower 2.0 at a download site, comparing the program to a freeware alternative and saying it isn't worth what I'm charging for it.
I've linked the review, but here are a few salient excerpts:
Manpower is pretty and costs $25...[the other] is freeware. Manpower does everything it says it does. The only real, functional difference I can find in casual use is that it divides the commands into categories (User, System, Library, File, etc.) and has a brief description of what each command does available before clicking and viewing the individual command, while the free [alternative] requires the user know what command he's looking for, and to type the command name into the input field.
In other words, Manpower offers navigation and search capabilities for OS X's man pages, not just displaying of them. The alternative (which is a nice little program, by the way) requires you to know what you are looking for.
This is a pretty big difference. It's the exact reason I wrote Manpower--I could not find a program that would give you a simple, easy-to-navigate overview of the man pages that come installed on OS X.
The review concludes with this advice:
Try them both. Keep the one that makes sense for you.
Fair enough. Individual users can decide whether the price I'm asking for a program that saves them time and effort, and (in the reviewer's grudging admission) is well-designed to boot, is worth it. I certainly think so.
I've released version 2.0 of Manpower, my man page viewer for OS X. Manpower provides a handy interface for searching, browsing, and viewing the manual pages--the documentation--for Unix commands. This new version adds some useful features, such as exporting a man page to PDF, and printing a man page, and also offers some usability improvements, such as a new built-in help viewer, an improved graphics engine, and remembering the window position when you re-launch the program. If you want to see what man pages are available on your system, or if you want an easier way of viewing man pages than typing in "man" and the command name in Terminal, then Manpower is worth your attention.
Brent Simmons has some good advice for aspiring indie Mac developers: Be persistent, be productive, have faith in yourself. All good points. But I'd also like to add something that he doesn't address:
Follow your own path.
Most indie Mac developers speak very warmly of the larger community of indie Mac developers. There's a whole ecosystem, a network, of blogs, mailing lists, and meetings, where developers can share ideas about technology, about product interface design, about marketing, and the like. It's a welcoming community, and if you share the community's interests, you can learn a great deal. (Simmons refers to this community as "your tribe.")
Still...there's also danger in diving too fully into the community.
One of the dangers of identifying too strongly with a community is drifting, almost unconsciously, into a kind of conformity. This can happen with the indie Mac developer community. Most members of this community share a strong set of assumptions about technology (Cocoa), interface design (Apple's fashion du jour), platforms (the Mac and, now, the iPhone), and so on. The result is that many well-crafted but utterly indistinct products hit the market. I see the mad stampede of Cocoa developers to release products for iPhone as evidence for my observation. (The number of cheap and free "to-do-list" iPhone apps has become a running joke, if not a cliche, among some Mac developers.)
I suggest that the strongest, most successful indie Mac developers achieve their success because they deliver unique products that target distinct niches. That is very hard to do. The technology that these developers use to create their products undoubtedly helps, but it's the product that matters. It solves enough pain for enough paying users that a viable business--one that provides the developer's living--is the result.
These developers include Brent Simmons (who is no longer an indie developer, having sold his flagship product to a larger company, and continuing to work on it for the new company), Gus Mueller, Daniel Jalkut, Michael Tsai, and Chris Smolinski, and others. These developers are, to varying degrees, members of the indie Mac developer community, and are widely respected for the success they have achieved. But I truly wonder if those who seek to emulate their success are looking at the right things. It's not a matter of technology, or interface design, or blogging. It's having the right product at the right time. It's also a matter of developing a portfolio of products and growing their user base over the years, gradually. Technology, interface design, websites/blogging, and other things are all aspects of a developer's success--but they are not everything.
I make these observations as one who is part of the indie developer community, but who also stands apart from it. I don't embrace the technological choices that most in the community make. In asking various members of the community for advice, I tend to get the same answers over and over again: Use the community's preferred technology (Cocoa). Use the community's preferred development environment (Xcode). Follow the same interface fashions that the community is following (source lists, heads-up-display, and so on). If I do all these things, these folks imply, I'll be successful as an indie developer.
I have to admit: I'm not as successful as I'd like to be. I wish my software sold better. But I think it's foolish to believe that I'd be an instant success if I embrace everything that the indie Mac community recommends. More likely, I'd simply blend into the crowd.
I have very specific reasons for focusing on the niche that I've chosen (leveraging the Mac's Unix underpinnings), with the technology I've chosen (Tcl/Tk). This approach lets me be productive, writing products that are interesting to me--and I have fun in the process. In other words, this approach keeps me in the development game. My efforts to learn the community's preferred approach have been nothing but tedious--the opposite of fun.
I have one moderately popular product, and several other ones that sell less well. The sum total of my sales isn't enough to live on. But the fact that I sell anything at all tells me that my approach is workable, at least for me.
Does it involve trade-offs? Certainly. I'm sure there are some users who do not buy my products because they do not conform to the prevailing fashion. But I am also sure that as I have worked to improve my products, to make them closer in look-and-feel to the prevailing fashions, my sales have improved. Also, while my niche necessarily limits the range of users who might be interested in my products, it also gives me focus. One cannot be all things to all people.
I think my approach has at least as much potential for success as following the indie Mac community's fashions. If I didn't follow the path I've chosen, I wouldn't be developing at all. So I will continue to follow this path, improve my existing products, release new products, and gradually grow my sales. I probably won't be a rich, full-time, indie Mac developer next week if I follow this path--but in five years, who knows?Thu, 30 Oct 2008
Various Mac rumour sites are now reporting that Apple's in-development release of Mac OS X, code-named Snow Leopard, will feature its major applications rewritten in Apple's Cocoa API. Supposedly, especially notable among these rewritten apps is Finder--the program that manages the user's interaction with the file system.
If true, this represents a strategic shift of some importance for Apple. Finder is currently written in Carbon, the updated API from the old Classic Mac OS. During the transition to OS X, Apple released Finder as a Carbon app to showcase what the Carbon frameworks could do. However, since Carbon has been deprecated for the next generation of OS X--it will only be maintained as a 32-bit framework, while Cocoa will support 64-bit (and Snow Leopard is all about 64-bit--it makes sense for Apple to rewrite Finder as a Cocoa application.
Some Mac users dislike the Finder for various interface quirks. John Gruber is notable among these critics. Some users, less informed than Gruber, attribute what they view as Finder's flaws to its use of Carbon, rather than to the way the program itself is designed, and imagine that a Cocoa Finder will solve all the issues with Finder. (For what it's worth, I'm neutral on the Finder--it does what I need it to do, and I don't have significant issues with it.)
Gruber, to his credit, understands that whatever flaws the Finder has will not be solved by being moved from C++ and Carbon to Objective-C and Cocoa. I'll link his post here, but it's brief, so it's worth quoting in full:
Everyone out there with a stiffy for the "rewritten in Cocoa" Snow Leopard Finder needs to get a grip. Cocoa is just an API. It is not some sort of magic technology where you just sprinkle a ton of square brackets in your source code and you instantly get a better UI. From a user's perspective, the Snow Leopard Finder is going to be pretty much the exact same turd we've had in Mac OS X all along.
His post is titled "Magic Cocoa Pixie Dust." Sprinkling a little bit--or a lot--of Cocoa on your program won't make it magically better. In fact, trying to add Cocoa can be downright painful.Fri, 24 Oct 2008
I've created a new mailing list for folks to get updates, special offers, and how-to tips on the software I release. If you want to stay in touch and find out about special offers, visit http://www.codebykevin.com/mailinglist.html to sign up.Tue, 14 Oct 2008
I've released version 2.4 of PacketStream, my GUI for the Mac's built-in network monitor, tcpdump. This release focuses on various UI improvements to give the user greater control of application windows, product updates, and display of their serial number. It also includes a new graphics engine for a better UI appearance, and includes a built-in help viewer, to work around what I consider to be extremely annoying behavior on the part of OS X's built-in help viewer. I hope you decide to check PacketStream 2.4 out.Wed, 08 Oct 2008
Apple has lifted the non-disclosure agreement on released versions of iPhone software. This means that programmers can publicly discuss development approaches and other subjects. Good.
Um, Apple? Since the hue and cry over the iPhone NDA has prompted you to change course, any chance you'll reconsider that 64-bit Carbon decision?
Well, it can't hurt to ask...Mon, 29 Sep 2008
"Great developers create amazing software for love as much as money. Take away the artistry and craftsmanship and you're left with someone pumping out crapware for a weekly paycheck."
Hear, hear. You don't have to be an iPhone/Cocoa developer to feel this way, either. One reason I'm such a strong advocate of Tk as a GUI toolkit is the sheer joy that developing in it gives me. It's a lot of fun.
And fun has positive benefits for both the developers and the users of his application. For the developer, as Eric Raymond has noted, "'fun' is therefore a sign of peak efficiency." It's a competitive advantage, allowing the developer to bring out better applications, more quickly. As well, the end user harvests the fruits of this work: applications made with care and attention to details, that do more than just the bare minimum to meet functional requirements.
Here's to fun!Wed, 24 Sep 2008
Since I'm not a Cocoa developer, I didn't join the mad stampede among indie Mac developers to whip up an application for the iPhone. On the surface, the platform sounds pretty good for Cocoa developers: Apple provides the store to sell the applications, handles all transactions, and takes a 30% cut of the revenue.
As things have evolved, though, the iPhone platform doesn't seem so sweet.
First, the iPhone development framework (or SDK) is controlled by Apple to the extent that the entire platform is under Non-Disclosure Agreement (NDA)--this means that developers can't talk about development techniques publicly, share source code, and the like. Given that the Cocoa community has thrived on the Mac OS X desktop because of public discussion of Cocoa--lots of conversations about how to solve knotty programming problems, and also advanced developers supporting and encouraging less experienced programmers--it seems that the iPhone development community will suffer from lack of same.
Second, Apple reserves the right to approve all applications for inclusion in the iPhone software store. Its criteria for rejecting applications are somewhat unclear, and may be downright capricious. Developers who have seen their applications rejected are rightly frustrated: they spend many weeks or even months of work developing the application, only to find that they will be unable to sell it.
The most recent development is also the most absurd, and the most draconian: Apple has placed rejection letters under NDA, meaning that developers cannot discuss the reason for their rejection publicly.
This has the effect of keeping the entire iPhone development community in the dark. It also has a sad, somewhat touching side effect: Cocoa developers are having their hearts broken by Apple. Brent Simmons' comments are a good example.
I hate to say this, but Apple's conduct with the iPhone platform isn't really out of character for the company at all. Apple brilliantly promotes its shiny new toys, whether it is a hardware product (iPod, iPhone) or a software framework (Cocoa). On the other hand, it has always been a secretive, controlling business that does not hesitate to throw anything under the train that has outlived its usefulness. (See Carbon.)
It seems that some Cocoa, or at least some iPhone, developers are getting a taste of the frustrations that Apple has visited on many in its development community. No one, it seems, is immune.
I'm going to continue developing for the Mac because, like Cocoa developers in their fashion, I find it the best, most powerful platform for commercial development in my preferred style--specifically, the combination of its Unix underpinnings and elegant desktop experience. But I have no illusions about Apple's benevolence. Cocoa/iPhone developers shouldn't either.Sun, 21 Sep 2008
If you've tried to visit this blog, or any of the related sites I host on this server (see the "home" link on the side of the blog page), you have undoubtedly noticed that the site's been down intermittently.
Put the blame on Hurricane Ike. Even though the storm made landfall in Texas, it retained a surprising amount of strength as it moved inland, northwards. My city, Cincinnati, was hit hard by winds. As a result, nearly a million households in the region lost power, some for several days.
Hurricane in Ohio? Yup.
Generous neighbors allowed my family to tap into their generator for a few hours each day, enough to cool off the food in our refrigerator, and also to power up my server long enough to answer e-mail, and get the dozen or so websites I host up for a while.
The worst, thankfully, is over, and the lights are back on. And we're back in business.
Sidenote: This situation--a power outage knocking out my Internet access--is the usual argument made against hosting your own websites on your own machine. Point taken. I'll never achieve the 99.9% uptime that commercial ISP's offer, and as a result, I have no desire to host anything but my company's sites. On the other hand, a hosting presence on the scale that my company uses would cost hundreds or even thousands of dollars a month. That's a lot of overhead, and the argument doesn't change even when the sites are down for a few days. I am going to be getting a generator, however.Sat, 30 Aug 2008
I've updated and gathered many of the Tk components I've created to improve the look and feel of my apps on OS X, and am now releasing them for use by other developers from the Code by Kevin website. I've maintained and offered some of these libraries in the past, but they've been scattered around the Internet, and have also been included with other packages I no longer use or maintain. The packages and documentation I'm offering here represent the state of my art: I hope other developers find them useful.
The starting point for the packages is http://www.codebykevin.com/opensource. Enjoy.Wed, 27 Aug 2008
More than one Mac developer has told me that once I "get" Cocoa, I will wonder why I ever wanted to write code in any other framework. It's a joy to develop in, they say. It's elegant and well-designed. Just keep working at it, they say, and eventually I'll fall in love too.
Well, with all due respect to these fine developers, and having invested many, many months of effort trying to get traction with Cocoa, I must disagree. I don't like Cocoa.
Cocoa offers essentially one avenue to develop GUI's. You can really only build a GUI using Interface Builder: while it's technically possible to specify a user interface in code, it's not well-supported or well-documented. This is in contrast to nearly every other toolkit out there, where GUI builders are available but not essential. For me, this is a hindrance to my productivity rather than a help. I'm accustomed to specifying my GUI in code, by hand; this is how I'm most comfortable. The fact that Interface Builder takes so much code out of the equation (not only the layout of the widgets but the connections between those widgets and the actions they perform) is what I dislike about it. This is not an idle complaint, either. According to Ronald Oussoren, a prominent Cocoa and Python developer, "There is a risk for creating greatly obfuscated programs, because important parts of your program aren't actually in code."
Learning Cocoa is also requiring me to completely reinvent the way I develop. In the process of learning Cocoa, I'm having to learn two separate languages, C and Objective C; as I've written before, this is proving a slow process. In addition to the overhead of learning two new languages, I'm also having to learn the process of developing with a compiled language, rather than a scripting language. It's a lot slower, because you have to re-compile each time you make a change. It's also a lot more complex, because you have to manage memory yourself. Mastering Cocoa would afford me a powerful toolkit--more powerful in some ways than Tcl/Tk and Python, my preferred technologies--but I would lose a great deal of speed and productivity in the process.
It is true that Cocoa can be accessed from some scripting languages. For instance, Python has a well-developed Cocoa binding called PyObjC. (Ronald Oussoren, whom I quoted previously, is the current maintainer of PyObjC.) However, while it avoids the difficulty of using Objective-C directly, PyObjC still requires heavy use of Interface Builder. Worse, PyObjC is currently in a heavy state of flux; it has undergone major updates in the past year, but most of its documentation and tutorials are outdated. The best current approach to learning PyObjC seems to be to learn Cocoa via Objective-C, then translate that knowledge into Python. This means getting on the C/Objective-C treadmill before you can even get to Python. This strikes me as, at the very least, inefficient.
The worst part of learning Cocoa is how much time it's taking me to reach a level remotely comparable to where I currently stand with Tcl/Tk and Python/Tk. It really is a form of shaving yaks. Mucking around with Cocoa is one reason I've gone seven months between releases for PortAuthority and Phynchronicity. I'm still at a beginner level with Cocoa; by contrast, I'm a fairly advanced developer with Tcl/Tk and improving rapidly with Python/Tk. If I'm going to port my applications to a different technology, I want it to be at most a lateral move in complexity. This is how I added Python as a development language to my toolbox; learning Python, and deploying an application in it, took me a couple of months of steady effort. It didn't take months of work just to get to the starting line.
Whatever virtues Cocoa has from a user standpoint do not offset the major obstacles that it presents me from a developer standpoint. Learning Cocoa is proving to be a tremendous, tiresome drain on my productivity as a developer, and I am no longer willing to slow my pace of application development on it.Fri, 08 Aug 2008
Today I've released version 2.2 of Phynchronicity, my GUI for the Fink Unix-software package management system on Mac OS X. This release adds several improvements, including a faster display of all Fink packages; Growl support; and various UI improvements to give the user greater control of application windows, product updates, and display of their serial number. It's a free upgrade for registered users. If you are a Fink user and are tired of using obsolete, unmaintained GUI tools for Fink, give Phynchronicity a try.
I want everyone to know that, despite my frequent ruminations about Apple essentially forcing developers to migrate to their privileged Cocoa frameworks, I haven't been neglecting my products. Today I released a new version of PortAuthority, and major and/or minor updates of all of my other products are also in the works.
For my products, updates tend to fall into two categories: application-specific improvements; and infrastructure improvements that can be added to each of my programs. This means that I often release updates in clusters, because they reflect improvements in frameworks and extensions that I use across my applications.
It's been seven months since the last release. PortAuthority is fairly mature and bug-free as a product, so there is less need to update it frequently. However, the new release contains some useful new features, including a faster display of all MacPorts packages; Growl support; and various UI improvements to give the user greater control of application windows, product updates, and display of their serial number.
2.6 is a free update to registered users. If you use PortAuthority, you'll want to install the new version.Fri, 25 Jul 2008
Jason Slack has posted a website that will document his efforts to port Tk to run on top of Cocoa, instead of Carbon.
To keep abreast of the project, visit http://softwareforeveryone.info, and click on "Projects/Tcl-Tk Work" or "blog."
Thanks, Jason! Your hard work on this project is much-appreciated.
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?
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.
But Objective-C, at its heart, is a small suite of extensions to C that add object-oriented capabilities to the language. What this means is that, despite the very different approaches to programming between Objective-C and C, you really need to know C.
Problem is, C is hard if you are coming to the language from a higher-level "scripting" language, as I am.
In general, programming languages work like math. If you remember algebra, you'd have an equation and some variables--x and y--and you've have to find the value of x or y. Programming languages use variables in a similar fashion, to perform manipulations on data.
The difference between a scripting language such as Tcl and C is how those variables, and the operations on them, are established. A scripting language is also called an "interpreted" language--the code in the language is executed by a separate program called an "interpreter." In the case of Tcl, the interpreter is a small program called tclsh. In an interpreted language, variables can be created and manipulated very easily, and the interpreter takes care of all the details of executing the code--making sure there's enough memory for your data, for instance, and making sure that numbers and words are handled appropriately (you can't perform math operations on something that isn't a number!).
In C, and in other compiled languages such as Objective-C, you have to handle a lot of details yourself. When setting up a variable, you have to make sure it's identified as a number (such as an "int," for integer) or word ("char," short for "character"). You have to set up memory for the various tasks your program is going to perform. And then you have to compile your code into an executable program. There's no interpreter involved. (Most interpreted langauges, in fact, are themselves written in a lower-level compiled language such as C--Tcl is written in C.)
So I've been working through an introduction to C programming, co-written by a noted Mac developer, and trying to map what I already know about programming into C. The translation process is an imperfect one, because scripting languages have allowed me to work at a fairly high level of abstraction. I can write code that solves my problems and not worry too much about how my code is actually executed by the computer; the interpreter takes care of that. Picking up a second scripting language (Python) wasn't terribly difficult after I gained proficiency in one (Tcl), because they operate at the same level of abstraction.
Learning C requires a lower level of abstraction. Programming in C requires a lot more interaction with how the computer actually executes your code: allocating memory, for instance. I have to take more steps to allocate and release memory, to make sure all my variables are correctly defined, and so on. It's also slower to develop in C: the code I write in C is actually compiled into machine language, the binary executable that is actually run by the computer's CPU. That explicit compilation step is unnecessary in scripting languages.
Now that I've spent a couple of weeks working through various exercises, it's time to start something real--that's the only way I truly learn something. The current project I'm working on is porting the code I use for generating and validating serial numbers (currently written in a scripting langauge) to C. It's proving harder than I expected, but thanks to some assistance on the comp.lang.c newsgroup, I'm making progress.
Once I get a bit further along, I will be ready to tackle Cocoa more in-depth, because I'll have more of a foundation on the compiled-language level of abstraction. After that, who knows? If I want to do any enhancements to Tcl or Tk, that will have to be done in C.
(Note: I didn't read this article until after I started learning C, but I certainly recognize the attitude contained therein: "Real programmers" program in, or at least know, C. Or, to directly quote the article: "Yep, we C programmers are elitist and proud of it.")Wed, 09 Jul 2008
When you have to make important decisions about your business, it may best to take matters into your own hands. In the case of my Mac software business, I've discussed at some length the Tk-Cocoa project in which another developer is working on moving my preferred toolkit, Tk, from a Carbon foundation to a Cocoa foundation. To date, no progress on this project has been publicly documented.
As a result, I've decided to take matters into my own hands a bit more. I'm diligently working through the new edition of Aaron Hillegass' textbook on Cocoa programming--considered by many to be the textbook on Cocoa programming. While it's slow going (I often feel like I'm taking baby steps), it is going more smoothly than my first serious exposure to Cocoa programming.
I'm not yet sure how I will incorporate my new learning about Cocoa into my software business. Develop and release a full-dress Cocoa application? Port my existing applications from Tk to Cocoa? Contribute to the Tk-Cocoa project--or start the project, if in fact it doesn't really exist? At this point it's too soon to say. But I do feel that getting a good grounding in Cocoa is necessary for the future of my software business--if only to stave off obsolescence, as Apple deprecates and perhaps removes the Carbon frameworks from OS X.Fri, 13 Jun 2008
This item by the developers of the Firefox browser caught my eye: it's an interesting take on how they are porting Firefox's Gecko rendering engine (the part that parses HTML and displays it to the screen--in short, the foundation) to use Cocoa instead of Carbon. (By way of comparison, Apple's Safari uses WebKit, a different open-source HTML engine.)
Unlike the Cocoa port of Qt, this does seem to result in some user-visible changes. Firefox 3.0 (now in final "release candidate" stage) is much more pleasant to use than Firefox 2.x, in large part because it gets the UI right. Here's an example from Firefox 2.0:
Kinda ugly, especially the button and search field...
Here's an example of Firefox 3.0:
It's not entirely surprising to me that the Mozilla developers have taken a different approach with their Cocoa port than the Trolltech/Qt developers. In the case of Trolltech, I understand the goal to be a drop-in replacement of the Carbon foundation with the Cocoa foundation. The changes are supposed to be invisible to Trolltech's customers, which are Mac developers: they are supposed to cause as little disruption as possible. By contrast, Mozilla's update of Gecko coincides with a major update of an application, Firefox: changes are expected and even desired. Many users complained about what they see as Firefox's poor integration with OS X. Firefox 3.0 should address that in a big way.Tue, 10 Jun 2008
Today I was playing with an alpha release of Qt, the cross-platform GUI toolkit, that is built on top of Apple's Cocoa development framework. Trolltech, Qt's developer, has been porting Qt to run on Cocoa instead of Carbon in order to allow its customers to compile high-performance 64-bit applications on the Mac; last year Apple announced that Cocoa would support 64-bit, but not Carbon.
A lot of people (myself included) have complained about Apple's decisions on Carbon. It seemed to us that pushing Cocoa development so strongly would require Carbon developers to do substantial rewrites of their programs as Cocoa applications, but this wouldn't necessarily yield any user-visible benefits. It would amount to a lateral move to the platform favored by Apple, with a better chance of keeping up with the direction of the OS X platform--and nothing else.
Trolltech, to its credit, listened to its Mac customers--they want 64-bit capability. So the company has plunged ahead with its port of Qt to Cocoa: it is the first cross-platform toolkit to outline a definite roadmap to a Cocoa port, and to release working code as the fruits of that effort.
So the alpha release of Cocoa Qt has 64-bit capability. Good. What else has improved, or even changed? The answer is what I suspected: Nothing. The applications look and behave the same as before. When the Cocoa port hits release-quality, end users won't notice anything different at all.
Here's an example of a Trolltech application running on top of Carbon:
If you look closely at these screen shots, they look pretty much the same. The main difference is that the Cocoa application (Qt Assistant) uses the Mac-style unified toolbar, rather than Trolltech's own cross-platform toolbar. But that can't be attributed to Cocoa--the unified toolbar is available to both Carbon and Cocoa applications, and the Carbon version of Qt Assistant also used the unified toolbar.
What Trolltech is doing is re-implmenting its own cross-platform Qt codebase with Cocoa as its foundation, rather than Carbon. When developers use Qt, they use Qt code to build their programs and don't call the underlying, platform-specific code (on the Mac, "QWindow" will presumably call "NSWindow"; I'm not sure what the corresponding calls on Windows and Unix/Linux would be)--that's the purpose of using a cross-platform toolkit. To end users, the fact that Qt's windows are being drawn to the screen by the Cocoa frameworks rather than the Carbon frameworks means nothing.
Of course, to developers and Trolltech itself, there is now one large distinction between Cocoa and Carbon: the former is a better hedge against obsolescence on the Mac. That means the Mac remains a viable platform for them. That is the only reason to move to Cocoa.
"In terms of programming effort, Cocoa gives you, the developer, much that is free and much that is low-cost. Of course, to become a productive Cocoa developer means becoming familiar with new concepts, design patterns, programming interfaces, and development tools, and this effort is not negligible. But familiarity yields greater productivity. Programming becomes largely an exercise in assembling the programmatic components that Cocoa provides along with the custom objects and code that define your program's particular logic, then fitting the whole assemblage together."
In short, while it may take some time to learn the Cocoa frameworks, that effort is richly rewarded down the road by easier and faster application development, and more elegant products.
I have no doubt that this is true. Many of the Mac applications I use daily--such as Safari, Mail, Vienna, and others--are written in Cocoa. They are clean, responsive, well-designed, and a pleasure to use.
Despite the undeniable value of the Cocoa frameworks, however--and despite Apple's promotion of those development frameworks as the preferred method of development on OS X--I'd like to suggest they are not the only route to powerful and even elegant Mac programs. There's a hidden jewel within OS X that provides a different, yet equally empowering, development environment: OS X's Unix underpininings.
Beneath the shiny Cocoa/Aqua surface, OS X is a certified Unix product--which means it has to pass a large battery of tests to be compliant with the rigorous standards of the Open Group, the organization that holds the actual Unix trademark. Apple has continually upgraded and updated the Unix layer of OS X over the years, and passed the tests for Unix certification with the release of Leopard.
What difference does this make for developers? Isn't Unix the ugly, geeky, command-line-oriented, user-unfriendly operating system that is the antithesis of Mac ease-of-use?
Well, yes and no. It is true that many, even most, Mac users have no interest in typing in Unix commands in Terminal. To a user accustomed to pointing-and-clicking a mouse and getting visual feedback, such commands are hard to remember, hard to understand, and hard to follow. As Eric Raymond, a prominent Unix developer and writer about software development practices, notes in his book The Art of Unix Programming:
The CLI style of early Unix has retained its utility long after the demise of teletypes for two reasons. One is that command-line and command-language interfaces are more expressive than visual interfaces, especially for complex tasks. The other is that CLI interfaces are highly scriptable--they readily support the combining of programs....Usually (though not always) CLIs have an advantage in concision as well. The disadvantage of the CLI style, of course, is that it almost always has high mnemonic load (low ease) and usually has low transparency. Most people (especially nontechnical end users) find such interfaces relatively cryptic and difficult to learn.
Despite this difficulty, these small, cryptic, narrowly-focused command-line programs still offer an incredibly powerful resource for developers. In Unix, it is trivially easy to link disparate programs into a larger whole, either via shell scripts, a GUI, or simply calling such programs from another command-line program. If the Mac development philosophy, as embodied in Cocoa, means mastering a complex but powerful framework, using the framework to provide the building blocks of your application, and then authoring the code and functionality that is unique to your application, the Unix development philosophy focuses on understanding how to link together the small, focused command-line tools of Unix into larger wholes, and authoring the code and functionality that is unique to your application.
Raymond quotes Doug McIlroy, who pioneered the concept of Unix pipes (a mechanism for communication between programs that allows the output of one program to be used as the input for another program), on the basics of the Unix approach to development: This is the Unix philosophy: Write programs that do one thing and do it well. Write programs to work together. Write programs to handle text streams, because that is a universal interface.
In short, just as Cocoa provides a framework, so too does the entire system of Unix provide a framework for Mac application development--rapid, powerful, Mac-native application development.
Raymond's The Art of Unix Programming has been a big influence on my thinking about Mac development. The idea that one can build large programs by chaining together many smaller ones, either with a GUI or another command-line program, is very cool--just as cool, in its way, as seeing what is possible with the Cocoa frameworks. I got my first exposure to the command-line five years ago, when I was trying to set up an iMac running OS X Server and had to edit a number of configuration files: all the documentation said to fire up Terminal and type in "sudo pico filename.txt." Huh? I had no idea what I was doing, but followed the instructions--and as I did more and more of this, I began playing around with the different command-line tools. In at least one instance, learning these command-line tools saved my server from being hacked.
But even as I saw the power of these tools, I also encountered frustration. They were hard to use, and required too much typing. It was in that observation that I saw a commercial opportunity: provide elegant Mac GUI's for these command-line tools. In doing this, I'm not the first: there's a long tradition of developers on Unix doing just this with GUI toolkits such as Tk, a powerful but lightweight GUI toolkit that first developed on Unix. (One of the most comman names for GUI applications on Unix is TkFoo, in recognition that a Tk GUI is driving a command-line tool named "foo.") A number of Cocoa developers on the Mac have done this with various command-line tools as well: it's not uncommon to see Cocoa GUI's, written in Objective-C or AppleScript Studio, for simple command-line tasks. (I've lost count of how many free tools there are for packing and unpacking zip file archives, for instance.)
Although I also use Tk as my toolkit because of its combination of simplicity and power, I'm trying to do more than assemble the latest iteration of "TkFoo." As Cocoa developers do with their framework, I'm trying to leverage the power of Unix to build elegant, sophisticated Mac programs. For example, my program PortAuthority provides a GUI for the MacPorts Unix software system on the Mac--but it's not a simple wrapper for the MacPorts command-line "port" tool. It begins by driving "port" and parsing its text output, but adds value by making it simple to browse MacPorts programs by category, something the MacPorts command-line program doesn't do; it also, via different command-line tools, the next version of PortAuthority will hook into such Mac-specific technologies as Growl for user notifications.
Another example: I am currently developing a file search tool with Growl, Quick Look, and Core Image integration, as well as other features, all achieved with command-line tools. The GUI provides the high-level view of the data and drives the various command-line utilities under the hood to get the requested data.
It's important to understand that although I'm using a GUI toolkit that originated on Unix, and using a design philosophy that differs from Cocoa programmers, I'm still striving as much as possible to meet Mac user expectations, something I've written about before. Using a toolkit other than Apple's featured one does not relieve me of my obligation to make my programs meet Mac user expectations, adhere to the platform's recommended UI guidelines, and so on. I do this, to the outmost extent permitted by the toolkit and by my own skill. Based on the sales my programs are achieving, I think I'm doing a decent job on that front.
To a large degree, my perspective on Mac development is a hybrid one, joining both the Unix and the traditional Mac approach. Raymond summarizes these two perspectives well:
Macintosh programmers are all about the user experience. They're architects and decorators. They design from the outside in, asking first "What kind of interaction do we want to support" and then building the application logic behind it to meet the demands of the user-interface design....By contrast, Unix people are all about infrastructure. We design from the inside out, building mighty engines to solve abstractly defined problems...We then wrap thin and often profoundly ugly interfaces around the engines.
I want to leverage the powerful engines, but I still want my applications to be all about the user experience.
I am troubled by Apple's promotion of Cocoa to the denigration of other GUI frameworks; in particular, Apple's relegation of Carbon to second-class status presents difficulties for developers using toolkits built on top of Carbon, which includes Tk. (Fortunately, Jason Slack's plan to port Tk to run on top of Cocoa mitigates this concern. Once Jason has released a stable port of Tk-Cocoa, I will even be able to claim, if only technically, that my programs are Cocoa applications.)
Despite my misgivings about the privileging of Cocoa, however, I must give Apple full credit for the investments and improvements it has made in the Unix components of OS X. This includes providing command-line, Unix-style access to many Mac-specific technologies, such as Core Image and Quick Look. Without the power of Unix under the hood of Mac OS X, my own work as a developer wouldn't be possible.
Not only does Unix provide a powerful framework for Mac development--it also provides a powerful platform for Unix developers to pursue commercial development opportunities. On other Unix platforms, most users don't pay for the software they use--the culture expects free software, both in the sense of free to tinker with the source code, and free as in "no-cost." The Mac culture, however, is one where users support independent commercial developers. On another Unix platform, it's unlikely that I'd earn any income at all from my software work.
It would be nice if Apple promoted Unix as heavily as they promote Cocoa. But the fact that they make Unix a first-class development platform on OS X (unlike, for instance, Carbon) is good enough for me.Fri, 23 May 2008
For the past couple of years I've been informally maintaining a Python/Tkinter wrapper for the Tk themed widget set, or ttk. This was adapted from a long-lost module first developed by Martin Franklin. I've used it in various projects, most extensively in Phynchronicity, and I've updated it as the ttk widgets have evolved and my own needs required. I'm not, however, enough of a Python wizard to completely implement the ttk widgets in Python.
Now I don't have to. Guilherme Polo has launched the Ttk to Tkinter project to provide the comprehensive Python version of the ttk widgets, under the auspices of the Google Summer of Code. The scope of his project is impressive: to add complete Ttk support to Python's core Tkinter library; to provide documentation; to migrate the standard Python editor, IDLE, to use the Ttk widgets (currently it uses the core Tkinter widgets, and looks rather outdated); and to provide sample code to illustrate how developers can use the widgets.
This is very cool indeed. When complete, this project will fully modernize the Tkinter widgets, which have tended to lag behind developments in Tk itself, and make Python/Tkinter a contender again in the GUI development races.
A complete overview of Guilherme's project can be found here.Sun, 18 May 2008
I've just released Manpower, which provides a GUI for viewing man pages on OS X.
This isn't the first program of this type that I've developed. For two years I developed VuMan, another man page viewer--first as open source, then as commercial software, then put out to pasture as open source again.
If you download and play with VuMan, you'll see that it has a somewhat clunky interface. I could never decide what I wanted the program to be--a viewer? A browser? A complete listing of man pages on your system? A tool for saving man pages in various formats? It did all of these things, but it made the program somewhat difficult to use. VuMan was also sluggish, calling out to multiple Mac command-line tools any time a user pressed a button.
Manpower is significantly different than VuMan. It lists all the man pages on your system, but it uses a more coherent design: it uses the same three-pane interface that Apple's Mail program, and iTunes, use. Man pages come up with a click of the mouse, not with selecting and pushing multiple buttons. Manpower also saves man pages, but only in basic text format.
Simplicity is the key here. By simplifying the feature set and design of the program, I think I've made it much easier and more pleasant to use. I have a few ideas of additional features to add, but they will be added sparingly--in a way that is consistent with the lightweight design of the program.
Not coincidentally, Manpower's simplicity and elegance is why I think the program justifies a $19.95 price tag. There are a lot of free man page viewers out there, but they either do less than Manpower, or are (in my view) more complicated to use. I don't think there's a free man page viewer out there (including VuMan) that is as clean and elegant as Manpower. I hope you'll agree.Tue, 06 May 2008
It appears that Jason Slack's project to port the core Tk libraries to Cocoa isn't vaporware. While he has not posted anything public about it, I've had a bit of private correspondence with him, and it seems that he has gotten under way. I've offered him assistance with testing and other feedback, so we'll see what comes of that. The long-term goal is to simply replace Tk's current Carbon implementation with a Cocoa-based implementation in my programs. In the meantime, I am working on removing my own applications' dependencies on Carbon, at least the dependencies I myself have added.
As one example, my programs make some use of Daniel Steffen's Carbon extensions, and I'm working on achieving that functionality by other means. So far I've been able to find what I need. For instance, one function in the Carbon library involves determining which program is frontmost on the user's screen, and bouncing the icon on the dock if my program is in the background; I've found I can get the same data by using AppleScript to call the Mac's System Events application.
Another example involves the user documentation of my programs. Currently I use Apple's Help Viewer application for my user help. I format my documentation according to Apple's guidelines, and use a Tcl extension I wrote myself, tclAppleHelp, to load and display the help. Eventually, I will be moving my user documentation online, to a special section of my main website, which I will load with a call to Apple's command-line "open" tool (which opens a document in its default application). This will remove another dependency on Carbon, and also work around the annoying behavior of Apple's Help Viewer in Leopard (the help window floats on top of all other applications). It may also help the visibility of my programs on Google, as there will be more material (user help) about them posted on the Internet.
In the coming months I'll be making these changes, and others, to my existing programs, as well as including them in new products under development. Now that the Cocoa port of Tk itself is under way--a task that I can contribute to, but which is too large for me to undertake myself--I feel energized to resume development of my own programs, and I'm bursting with ideas. What a wonderful thing to be able to concentrate on improving my applications for my customers, rather than rewriting them in an entirely different framework.Fri, 11 Apr 2008
It seems there is no escaping the ascendancy of Cocoa for Mac OS X developers. Since Apple announced last summer that it was moving its Carbon frameworks into maintenance mode-- with only bug fixes being made and no new features, like 64-bit support, being added--the long-term tides are running even more strongly against Carbon than I realized:
I've kind of halted work on new versions of my program for the time being to improve my facility with Objective-C, Cocoa's foundational development language. It is becoming more and more clear to me that I will have to integrate Cocoa into my work to a significant extent. It is simply unavoidable. Even if I do not completely rewrite my programs from Tcl and Python into Objective-C, it is obvious that I will have to know Cocoa and Objective-C to modify certain components I use. And it is difficult to imagine a single person being able to rewrite Tk Aqua from Carbon to Cocoa without some help.
The question for me is which path makes more sense, in terms of time: learning Cocoa, then rewriting my applications in Cocoa; or learning Cocoa, then rewriting the underlying toolkit of my applications in Cocoa. I don't know enough yet to make that decision. But, one way or another, Cocoa is becoming part of my work.Wed, 19 Mar 2008
The Tcl/Tk community has been accepted as a sponsoring organization for the Google Summer of Code. The Summer of Code is a program that offers student software developers the opportunity to contribute to open-source projects, supported by a nice stipend and guided by experienced mentors.
While no official projects are yet underway, I see two on the Tcl community's proposed list that are of particular interest to me: "TkCocoa" and "Tk Drag&Drop: Native OS X (Aqua) port." Both would greatly improve Tk on the Mac, and help to ensure its long-term direction.Mon, 03 Mar 2008
A couple of developments this past weekend prompted some thinking on my part about the software business, customer needs, and fashion.
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.Sun, 24 Feb 2008
Open-source code is a terrific resource for commercial developers, because it can save a lot of time and cost--I don't have to develop these items myself. Of course, it's incumbent on me to use the software in a manner that's consistent with their license. Some open-source code can only be used in other open-source projects, while others can be used in commercial products as well. The components I use come with commercial-friendly licensing terms.
I think it's important to do more than simply comply with the terms of an open-source license, however. I try to contribute to open-source projects as well. I've contributed documentation, bug reports, code patches, and code samples to the Tcl/Tk and Python software communities. In addition, I maintain an entire suite of software extensions and packages here. Whenever I develop a code package that improves my software and that I think can benefit others as well, I release it under an open-source license. (See http://tk-components.sourceforge.net/mactoolbar/index.html for one component that worked its way into my products over the past few months.)
In fact, that's what I've been working on the for the past few weeks--some open-source components that will eventually become part of new commercial products and my existing products as well. These components are geared toward improving the user interface of my programs, and will allow me to develop more polished products. It's my hope that other developers will be able to make use of my projects, much as I've been able to make use of the open-source work of others as well. That's what giving back is all about.Thu, 24 Jan 2008
As 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.Wed, 23 Jan 2008
Tcl developer Mark Roseman has put together TkDocs, a website that aims to serve as a resource for developing GUI's in Tk. It's not just a tutorial site, however--its goal is to be a complete resource, with discussions of Tk widgets, lots of screenshots, and (still in progress) screenshots of state-of-the-art Tk GUI's. When the site is complete, it should be an excellent starting point for anyone developing graphical interfaces with Tk.
Hey, Mark--feel free to poke around here if you need some material for the "gallery" section...
I've been doing a great deal of work updating each of my programs--PortAuthority, Phynchronicity, and PacketStream. The focus of these releases is Leopard compatability, updating the GUI base of my applications to Tk 8.5, and various refinements and improvements.
Making my applications Leopard-compatible means, among other things, changing their icons yet again. Apple has added a new 512-pixel application size for Leopard, which is much bigger than those supported by previous verisons of OS X. (Think 128 pixels.) Last year I purchased commercial icon sets from two vendors (WackyPixel and IcoZon), to use as my application and toolbar icons. These icons, however, weren't available at 512 pixels. As a result, I've switched to two excellent open-source libraries, Oxygen and Crystal, both of which are part of the KDE project. These icon sets blend in very well with OS X and can also scale up to 512 pixels.
Another part of Leopard compatibility is improved stability, courtesy of Tcl/Tk 8.5. Tk, my GUI toolkit of choice, recently hit a landmark release, as the new version is the biggest improvement in several years--it offers greatly improved integration with OS X. The older version of Tcl/Tk that I used (8.4.16) was also crash-prone on Leopard; 8.5 fixes several bugs in that respect, and my programs should run without a hitch now.
I've also added some new Tcl/Tk packages such as the TclMacBag library, which supports some custom Mac-style widgets that are not part of the core Tk library. This package has also helped me improve the look and feel of my programs in some respects.
Importantly, I am trying to maintain backward compatability in all of my programs: all have been tested on Tiger (OS X 10.4) and seem to run fine. Not everyone upgrades to the latest OS right away, and I want to support those customers still on Tiger.
I'm very pleased with the improvements I've made, and I hope you will agree once the programs are available. Look for them soon.