Skip to Main Content
2012-02-14 12:54 am (UTC)
Mostly, because disk space, bandwidth, and processor power gets cheaper
all the time
(Moore's Law applies pretty universally) and if we amortize the cost of what we think it will cost to support each additional icon over time, people pay up front but the up-front payment pays for the cost over time. By the time that up-front payment has expired, the disk space/bandwidth/processor power necessary to serve that icon has dropped to the point where the cost of supporting that icon is negligible.
Some people will almost certainly pay once and then continue to use that icon slot for the next ten years, but that's offset by the people who pay once and then use that icon slot for maybe a year before they get tired of using DW and wander off (and thus don't use the icon slot over the X years we counted on for amoritzation).
In addition, we'll still be guaranteed income from that account -- icon slots won't be usable without a corresponding paid account. So, we'll still be getting revenue from that account, and in fact might get
revenue from the account (people continuing to pay for their paid account because they don't want to lose access their icon slots, since they're more invested in having those icon slots -- enough to have paid for them -- where they might otherwise let the account lapse). So it's not like seed accounts in that you pay for them once and never pay again: you continue to pay for the paid account, and the one-time payment to increase the icon slot limit is used to cover the additional cost of those icons for the time period it takes for the cost of providing that service to drop.
We'll definitely price it so that $amount (the cost per icon slot) covers what we think it'll cost us to support the extra icons over time, not just over a single year (right now we're thinking four or five years sounds about right), and if things wind up being a disaster we'll be able to spot it early (Mark gets into that a bit more up
), but given how disk space and bandwidth costs drop over time we definitely think it's doable. Honestly the biggest cost associated with large numbers of icons isn't the disk space and transfer associated with it, it's the computational cost of loading all the icon keywords/displaying all the icons in the icon selector drop-down and the UI cost of figuring out how to display and manage them all. Don't get me wrong, that
a cost and it
computationally expensive to do it, but we can work on fixing that. Disk space and bandwidth is really a secondary concern, since those costs do drop over time.
EDIT, as something occurs to me: something else to keep in mind is, the cost of doing it the other way (yearly, the way LJ does their addons) is not insignificant -- administrative costs are still costs, and explaining pro-rating and mismatched renewals etc to people is
hard. By the time I quit LJ, I'd say explaining how the add-ons worked to people and troubleshooting issues with add-on related problems took up at least half, and possibly up to three-quarters, of a single person's 40-hour workweek. We don't have the staff to do that kind of support, especially since anything having to do with payments requires direct staff intervention and can't be done by volunteers; it involves sensitive information. We just don't have the staff for that, and anything that can simplify things is better.
Reply to this
Thread from start
Post a comment in response:
This account has disabled anonymous posting.
You can comment on this post while signed in with an account from many other sites, once you have confirmed your email address.
Sign in using OpenID
If you don't have an account you can
create one now
HTML doesn't work in the subject.
Check spelling during preview
This account is set to log the IP addresses of everyone who comments.
Links will be displayed as unclickable URLs to help prevent spam.
Log in with OpenID?
Forget your password?
Site and Journal Search
Buy Dreamwidth Services
Gift a Random User
Site and Account