Keith Hopper's proposal for software subscription schemes, or 'subscriptionware', surely holds a lot of promise, and some of the points he made are worth expanding.
As Keith stated, similar schemes are already up and running: take Argonet, who charge subscribers slightly more than some ISPs, in return for supplying and maintaining a suite of 'click and go' Internet software.
More importantly, we know that the relatively low cost of Acorn software occasionally engenders the dismay of developers, who argue that Acorn software is under-priced, given the lower profit margins permissible. It should be reiterated, therefore, that the incentive of a subscription is twofold. For developers, the potential exists to recoup a share of the income that higher software prices would otherwise bring (at�the risk of reducing their customer base), whilst ensuring that continued development has a secured market. For users, the knowledge that they directly support software development provides encouragement to keep up-to-date with newer releases. Let's clarify what's entailed by the development and support a subscription provides.
Fundamentally, a subscription subsidises development of software updates, the exception being major additions, enhancements, etc, for which a higher charge is more appropriate. In other words, the subscription scheme is geared to enabling development of an excellent and/or promising piece of software to continue, rather than providing extra investment to finish and polish off a package because it initially didn't come up to scratch.
To this end, bug fixes should not be charged for - if a simple workaround or patch can be made available, the developer should offer it, especially when it impinges on the functionality of a package; otherwise, it seems fair to let non-essential bugs remain unfixed until the next major update. This is worth bearing in mind when the opportunity to capture a market, the pressure to release new products at major shows and/or the sheer size of a software package, may lead inevitably to an initial release containing undetected bugs.
Since a fee is being paid by a subscriber, updates should be provided, rather than seeing twelve months or more elapse without any development. This is important to ensure the incentive behind the subscription remains, not least when the increasing use of websites means minor updates, or bug fixes, can be distributed at negligible cost. Specifically, it would seem reasonable to offer, at the very least, one update each year, the exception again being major updates or new releases, for which a subscriber's discount could be offered.
Perhaps another point to emphasise, given Keith's original proposal, is that the subscription is charged according to the usage to which the software is put. Just as a site licence costs more than a single copy of a software package, a business where ten copies of the package are installed pays more than a subscriber using one copy of the software. Similarly, schools and colleges could be expected to pay a pro rata subscription, possibly lowered by the offer of some form of educational discount.
How then do you determine the cost of a subscription? Keith's example figures suggested a rate fixed at x% of a package's purchase price. This is noteworthy in that the subscription rises to reflect necessary increases to the cost of the software itself, for example when an extensively enhanced new release is made.
If it is acceptable to price the subscription at such a percentage, it seems important to determine what proportion of the subscription actually goes toward development of the software. Should there be some form of guarantee that the majority of the subscription covers software development, rather than administration costs, or would the cost of promotional material also be covered, given that it potentially increases the user base of a package and subsequently the market for further developments?
One suggested breakdown is as follows:
A potentially 'hidden' cost that Keith touched upon is that of the fee for the programmer(s), arguably chargeable because their livelihood and the continued development of software go hand in hand. Certainly, if a subscription could include a proportion attributable to a programming fee, I wouldn't object, as long as the end-product of the subscription remains the enhancement and development of the software. If such a fee meant a rise of, say, £5-£10 per subscription, again I don't see this as unreasonable, particularly given the use I'd hope to derive from the software. What then of users who prefer not to enter into a subscription scheme?
As Keith suggested, they would retain the use of their software and are equally able to upgrade when newer versions and updates are released. The benefit to a subscriber is that these releases should be discounted, encouraging a subscriber to remain within the subscription scheme. How then is the proposed 're-entry' fee determined, for when a former subscriber decides to rejoin a scheme? One possibility is that it is already included as part of the administration costs cited above in the suggested breakdown, so may be separately recharged.
Keith's conclusion that non-Acorn packages threaten to overtake their Acorn counterparts may seem exaggerated, but I have a niggling suspicion that, for developers to survive in what's a seemingly PC-dominated world, the policy of offering virtually free support and upgrades may well need serious reappraisal in the not too distant future.
As a closing remark, consider this: with the possible exception of our excellent Acorn magazines, how many of us think very little of paying out £20-£40 for magazine subscriptions where, after all, each magazine may only be read in its entirety once or twice? Given that, is a software subscription scheme costing an annual £20 or so on top of the purchase price really so expensive as it might first seem?
Disagree? Then reply!