The real problem in thinking of software as an item which you sell is that that is the end of the transaction as far as you think of it, but the customer then expects support. Trying to charge for that support then becomes problematic from their perspective. But you have no choice but to charge for support, because you can’t commit potentially unlimited support time to a one-time purchase price. You price yourself out of the market that way.

Instead, you have to sell them on the support contract idea on a continuing basis up-front, so that they know what they’re buying. Selling a theme at $60 one-time is basically the same as selling them the theme+support for $5 a month (first year upfront). Then at the end of the year, you can resell them the same support contract for continuing access to your support infrastructure. Continuing business. And if your money is coming from offering support channels and continuing upgrades and such, and you do good work, you’ll have a steady business with loyal clients.

Improve the support channel, create a continuing sales structure, then sell the same themes you couldn’t make money on with one-time costs, but on a continuing upgrade basis. Perhaps that’s a better model.

As you say, it’s not a manufactured good and you’re selling licenses. You just have to sell an additional license on top of the GPL license you supply the software under. It’s exactly what we do.

I think SaaS is the answer for many developers today, and that’s a massive growth area right now, and a very lucrative one.

As for what you’re selling… well, really, what this comes down to is the fallacy that software is a manufactured good. Generally, it’s not. Software really is a creative expression. The act creating software is a service, just like the act of creating a painting for a commission.

Think about programming jobs for a moment. How many programmers are there in the world, making a living by writing code? Answer: a lot. How many of them actually make their money by selling software to the public? (Hint: it’s under 10%.)

Virtually all software made is custom-made. Think of the ATM you use every few days. Was the software in it purchased off-the-shelf? Did they install Microsoft-ATM on it? Think of the software in your TV remote. Or in the TV. Or the software in your refrigerator, keeping itself cool. Almost all software is purpose made. And not just embedded software, go to any major chain store and look at their Point-Of-Sale system really closely. Large companies didn’t buy a POS system off the shelf, they wrote their own, customized for their needs. They employ a large staff of programmers somewhere to manage and change that system.

Programming, as a job, isn’t about selling product. It’s about writing code. More to the point, it’s about getting paid to write code on a continuing basis. Virtually nobody makes money selling software. Even Microsoft makes the largest share of their money from Office licensing contracts (they make over $13 billion a year from their business division). They’re not selling software, they’re selling systems and configuration and services. Hell, Apple is really a hardware company nowadays.

Creating software is a service industry, not a retail sales one. So you have to approach it as such, and find those people willing to pay you to create software for their needs. This does mean that you program a lot more code, but that the business you’re in, you know?

The advantage of structuring your business in this way is that it changes your perspective. If you’re focused on creating a product then selling that product as many times as possible, then you’ll put the most effort into that as you perceive it to be the money maker. However, if you change your outlook to consider the support channel as your main money maker, because that’s where you get your paying customers from, then you’ll put more resources into that, provide better support, gain more customer loyalty, and gain more paying customers.

The support channel is where an independent programmer is most likely to get paid, not from creating and selling product.

But piracy is not what we’re talking about, and is an entirely different issue.

Where GPL struggles is that there’s little in the way of progressive pricing. You can add terms to your support contracts that make it so, but if your client doesn’t want or need support then that’s it – a corporate could reuse your code many times over. Consequently small, honest users pay more in GPL land than large users. The same, kind of, applies in piracy except small and dishonest pay less than the large organisations who tend to be very shy of using pirated software. I’ve seen open source code used extensively in corporates and known for sure that not a penny ever went towards the projects that supplied it.

So GPL is great for mass market because it gives you numbers amongst people who aren’t going to spend much anyway. It’s also great for coders who want to share code. But it’s not about making a business – it’s about a license. Your business has to come from something else. In Automattic’s case it’s about automated software services (Akismet, VaultPress, VIP hosting) + human services (VIP Support, consultancy) and that works great for them. But to say that all small companies can go in that direction isn’t good, because some just aren’t set up for working with larger markets. We aren’t, and our attempt at a themes club was a spectacu.la failure (pardon the pun.)

Plus, spending all your time railing against “pirates” is just unhealthy, man.

In response to the sentiment that it “just seems wrong” for people to redistribute commercial WP themes or plugins, I strongly object. Anyone who develops and releases derivative works of GPL software (WordPress) should know what they’re signing up for by doing that. Giving someone else crap for taking actions that are explicitly allowed by the license you distribute under is disingenuous, hypocritical, and just plain wrong.

The way I see it, there are two main camps in the WP dev community that are disturbed by this aspect of the license:

#1 – Devs who didn’t take the time to consider and understand the license going in, and now feel like the rug is getting pulled out from under them when they discover that by creating a derivative work based on WP they were inherently agreeing to distribute it under the GPL.

#2 – People who actually partially understood the GPL going in, at least enough to know that they didn’t want to use it (due to a perceived or real incompatibility with their business model), and then reluctantly switched to the GPL after Matt started getting more vocal about compliance recently, and decided to go with the “yeah, but that’s really not cool, man” approach to redistribution.

I think the solution for both is the same: learn about the GPL and why it’s actually a good thing. A good place to start might be to understand how the GPL helped make WP (the product they love) as great as it is today; Matt has said a lot on this subject.

At the end of the day if you still don’t like the GPL and don’t want to use it, that’s OK, Just accept the fact that it also means you can’t base your work on WP, taking advantage of the work of all the people who did choose to support it (by contributing to WP), with the understanding that those freedoms (including redistribution of derivative works) would be preserved as required by the license.

“Most companies would consider that software piracy; we consider it free marketing.”

And:

Software is largely a service industry operating under the persistent but unfounded delusion that it is a manufacturing industry.

Both of these quotes come from a chapter, “The Magic Cauldron,” with the latter coming from a section aptly named “The Manufacturing Delusion.” It ought to be required reading.

References:

http://www.catb.org/~esr/writings/magic-cauldron/magic-cauldron-9.html
http://www.catb.org/~esr/writings/magic-cauldron/magic-cauldron-3.html