Matt Gemmell

My new book CHANGER is out now!

An action-adventure novel — book 1 in the KESTREL series.

★★★★★ — Amazon

Selling Source Code

Development & Source 5 min read

I want to solicit some feedback on the idea of selling source code for the iPad/iPhone and/or Mac platforms. It’s something that’s commonplace (and popular) on other platforms like .NET and Java, but for whatever reason it’s never taken off on the Mac. I think that there’s potentially a reasonable market, particularly for iPhone/iPad, and I’d be interested in your thoughts.

Before we start, let me assure you: all of my Cocoa source code which has been free and open source up until now will continue to be free and open source. This is a discussion regarding future code only, and indeed only a subset thereof. It’s an additional avenue, not a change of policy. I also very strongly hope that response to this post won’t turn into a debate about whether “all code should be free”, and such - I’m a very prominent contributor to the open source community for the Mac and iPhone, and I think my position in that regard speaks for itself; this isn’t intended to be a philosophical debate about software freedom-as-in-anything.

As a self-employed software engineer, I understand the value of my time. I not only have an hourly rate, but I also grasp the value of getting ahead of a schedule, or being able to meet an aggressive schedule without having to compromise functionality or vision. The idea of paying others for quality source code is something I find very easy to accept and understand.

If I can pay $150 and get something that really does fit my needs, and it would save me more than a couple of hours of my own time, then it’s clearly a win in terms of time and money. I’d be crazy not to pay for it. That’s as true for compiled software as it is for source code, and it’s also just as true (for the right return on investment) if the code costs $5,000.

You might have to be more selective with source code (because unlike with apps, there’s often a clear dividing line between what fits the bill and what’s useless to you) but the general value proposition is similar.

For whatever reason, there are only a handful of people selling code components on the Apple platforms. I suspect that’s less about the market and much more about perceived worthiness; we do all tend to collectively reinforce the perception that only the very best stuff will do, and it’s incredibly difficult to convince yourself your code is even worthy of being open source, much less paid for in its raw form. I’ve had to twist the arms of so many Mac developers to convince them that they have a component worth sharing with others.

I have a component (as usual, it’s a GUI-focused piece of code; something visual) in the works right now for iPad, and I’m planning to make the code available for licensing to use in your apps for a fee. I think it’s important to test the market and see if there’s interest, and if it can be a viable part of my overall business. I’ll be giving more details in due course, including showing demos, sharing API documentation and so forth.

I’ve been thinking about how to approach the licensing/payment, and have had a few discussions on the matter with friends and colleagues. It all boils down to two main issues: pricing, and what you get for your money. I have a few thoughts on this.

Source must be included

I would very rarely buy a precompiled component. Sure, if it’s a situation where the specific algorithm or integration is what you’re paying for and you’d conceivably rarely (if ever) want to tweak it (barcode scanning, talking to a piece of specialist hardware), then maybe.

Generally, though, what you’re paying for is an API where the implementation and behaviour is important, and needs to be up for inspection and modification - at least as a last resort. I would always feel far more secure if I had the code. I’d thus almost certainly want to sell the code, rather than just a library or framework.

Price perception is important

The pricing of source components is all over the place; it varies incredibly wildly. Entry-level is in the tens of dollars, and you can also readily pay many thousands. There isn’t a direct relationship between type of component and price, and there’s no clear model. My personal impression is that pricing based on the actual number of hours you’d need to spend creating it yourself (times some average hourly rate) is largely fantasy; for anything non-trivial you’re immediately in the thousands of dollars range.

I think there’s a major psychological barrier towards paying that amount unless you can pass the cost directly to a client or your company. I also feel that the majority of the market for iPad/iPhone and Mac are small shops, and often individuals. They’re not going to pay for multi-thousand-dollar components. For well-designed (visually, and every bit as importantly but considerably more rarely, architecturally) GUI components with a reasonably general use scenario, I think the ideal entry-level price point is probably somewhere around the $150-200 range.

I’m not certain about that, but I do know that going much lower very quickly puts you into pointless territory. At some point, you have to target those who understand the value of their own time, and are willing to spend money to make more money.

Tiered licenses

I think that pricing at a single flat rate is unrealistic, even though it’s unarguably a bonus for the buyer. We don’t price software at a flat rate (you buy a license to use it on a fixed number of machines, often one), and we don’t price our consulting services at a flat rate in that sense (if multiple clients want the same piece of work done, they each pay for that work; albeit perhaps at a reduced rate if you have a pre-made component of your own and choose to offer such a discount).

The question is how to tier. Historically, components have been priced per “developer seat”, whatever that really means in practice. Bigger companies pay more by virtue of the fact they’re bigger companies. I don’t think that model works on these platforms; there are just very few big companies, but a huge number of very small companies each selling multiple applications. I think that the right model thus becomes per-app.

My gut says that a three-tier system would fit the bill:

  1. The base tier which almost everyone will go for, perhaps allowing use in just a single application.
  2. A middle tier allowing use in up to a certain small number of apps, which covers the bulk of the market (most people release only a handful of apps). This would be priced as a very small multiple of the base tier.
  3. A top, premium tier which constitutes an unlimited license. Rarely if ever purchased, but fair in those situations.

And naturally, you offer upgrades at any time by simply paying the difference.

These are all difficult issues, but I think this is an area that we shy away from, and it’s needlessly hindering a legitimate and healthy part of the software industry on our favourite platforms. We’re all already clients of each other’s professional services, and customers for software, so there doesn’t seem to be any reason that selling code components wouldn’t at least be viable.

I’d love to hear your thoughts on any of this, either via the comments here, on Twitter (I’m mattgemmell), or in an email (my contact details are here).