You can follow Don’s advice by visiting the Mozilla Add-On Workshop mashup page, and hopefully videos of all presentations will be available before long.
Yup, I’m back from the Mozilla Add-On Workshop (MAOW) in Berlin, and recovered from my 11 hour journey home. A special mention must go to the baggage handlers at Stockholm Arlanda airport whose heroic efforts allowed me to savour an unexpected 3 hour addition to my journey: my luggage’s progress from plane to collection belt vividly evoking, as it did, the great glacial movements that helped to sculpt this fine peninsula.
My own contribution to the MAOW was probably summed up by this sympathetic portrait of community legend KaiRo, attempting to get his presentation to work:

The one talk where I would like to have contributed more was probably Daniel Glazman‘s on making money with add-ons. Without rehashing all the talk, Daniel was essentially proposing that addons.mozilla.org (AMO) needs a system for micro-payments (he was proposing around $1 / download I recall), so that add-on developers can charge for their works. I should make it absolutely clear that I am not part of the AMO organisation, and I should also make it clear that Rey Bango, who is, is totally committed to enabling whatever makes sense for add-on developers.
But still, my personal opinion is that such a micro-payment system is not a recipe for success for developers, users, or Mozilla as a whole. Firstly, today there is no truly widespread payment system that users will easy use for 1-click purchasing on a new install of Firefox. Requiring registration to a payment service before a user can fully use AMO seems an uncomfortable arrangement to me.
Secondly, how would you price such software? Daniel was suggesting a figure of $1 for a good add-on. I would estimate that even in the affluent west, that is already enough to make many users search further to find something of approximate functionality, and that pricing would need to be much, much lower to ensure clicks (if such a system even existed). Moreover, for the many Firefox users in the developing world, $1 is not a micro payment. And there is a great wealth of add-ons today (over 4,000, soon to hit 5,000). As Daniel pointed out, if you area not near to the top of a search, you might be invisible. However, if you are successful in achieving visibility for your add-on, pay-for-play immediately incentivises the user to search further if their first results.
Thirdly, how are you going to compete? If you are producing open source add-ons, any add-on which achieved traction would be subject to forking. We would probably need to be talking about closed-source add-ons. And this would inevitable need some license key mechanism, as Daniel indicated. Again, uncomfortable.
Fourth, what kind of license would you be selling? How committed would a developer have to be to forward compatibility to sell and add-on?
Now, all these questions can all be answered to a greater or lesser state of satisfaction, but the likelihood of gouging a successful business out of such an arrangement seems pretty thin to me. Let us consider two perspectives.
One, every business today which relies upon charging for access to something which has no marginal (or opportunity) cost of unit production (software, music, information in general) is facing a challenge in the face of the network – rightly or wrongly, long established businesses which are charging for access are in difficulty. The App Store on the iPhone may buck this trend, but it does not invalidate it. The Internet is eroding all of these business models, even the ability of television networks to command exclusive audiences for sporting events (to Don King’s dismay, one presumes).
Two: software is not intrinsically valuable, not in monetary terms. Anyone who has attempted to rate the value of software using the COCOMO methodology realises this. Software’s value is a function of its usage. If one placed market values on Windows, UNIX, Linux and Mac OS X, their relative values would not have a direct relationship to the quality of code, but to the profile of their usage.
So, how do we make money with software? Well, we should consider what you can monetise software against, and a good rule of thumb is to monetise against something that does have an (implicit) cost of unit production. If you want to make money with software, charging the user for a copy implies either a heavily locked-down system (as Daniel suggested in his talk), an entrenched market position (such as the ability to have software bundled), or both.
But there are other ways to make money from software. In most cases, I would suggest we might think of a way to offer access to a service via an add-on. Allowing users the benefit of particular running infrastructure over time clearly has an associated cost that they may be inclined to pay for. Many free services (Gmail, Twitter) even allow such access for free, and make money by displaying adverts to users (in the case of Gmail) or by raising capital by the sheer promise offered by millions upon millions of users (in the case of Twitter). Twitter does not yet have a clear business model, after all, but you can bet that Jack Dorsey has done alright. In these straightened times, VC opportunites may be fewer and further between – but there certainly are many other online commercial opportunities that do exist and could capture more market share with add-ons. Considering an add-on like CoolIris, I can imagine being certified compatible with the add-on would be worth money to those sites whose value is based on offering up image-content.
And so I do not agree with the advice that add-on developers should attempt to build something cool or, in the parlance of our times, “shiny”, and then try to make money by selling access, at least, not if they want to earn a good living. The result may be the coolest piece of software that no one has ever heard of. And let us not forget the power and influence of those that scratch their own itch, or even those great souls who enjoy scratching the itches of others. Freely available software will always command a consumer’s preference in an open system.
I hope we can have a good debate about what developers need from AMO, and those who wish to build, or augment a business using AMO, can get their points across and feel their needs are met, just as those who wish to build free / gratis software hopefully will. A big thanks to Daniel for raising the topic and addressing it so squarely.
I mulled all this over on the way home, until I managed to find somewhere selling English newspapers at which point I needed to switch my attention to controlling the pedantic rage that burns inside with the intensity of a thousand suns. Sadly, I failed. And so I offer this picture. I am sure that Mr Gough’s own writing is most illuminating, but, copy editors note, it is hard to take recommendations from an author seriously when they include incorrect spellings of pronouns.
