This email's going to be long (like any of mine aren't, heh) and deal  
with lots of numbers. If you want the bottom line, we'll give it up  
front and then you can follow our reasoning if you want. :)

To cover a lot of background here, and to answer questions that might  
arise, I've got a sort of "business FAQs" page set up on the Wiki,  
for things I've heard people asking:

http://wiki.dwscoalition.org/notes/Dreamwidth.org:_Business_FAQs

This email assumes that you're familiar with much of the material in  
there.

After lots and lots of playing around with numbers, we have finally  
finalized our account structure and price points. (We're still  
working on what each account's levels will be, for things that have  
levels, so we don't have a *definite* answer for things like "how  
many userpics will each account level get". That's forthcoming.  
Assume that the levels will be roughly comprable with LJ's levels,  
with a little extra here and there.)

ACCOUNT STRUCTURE
-----------------

Our account structure will be:

* Free: costs nothing, gets access to basic site features
* Paid: costs, gets access to all site features
* Premium Paid: costs, gets access to all features at higher levels
* Permanent: Functionally equal to Premium Paid, with no expiration  
date; sold only on site launch

Free accounts will be able to do everything that free accounts on LJ  
can do, and paid accounts will be able to do everything that paid  
accounts on LJ can do (with the exception of things that we don't  
have in the DW codebase; see the Wiki for more details). Premium paid  
accounts will be able to do everything that paid accounts can do,  
only with higher limits, and permanent accounts will be functionally  
equal to premium paid, but with no expiration date. (In other words:  
a permanent account is a Premium Paid account that you never have to  
pay for again.)

Over time, as we add more DW-specific features, many of them will be  
paid features. Our philosophy with that is that any changes for the  
overall health of the site (usability changes, fixing bugs, making an  
existing feature work better) will be available to all account  
levels, while anything that costs us money to offer, or anything  
that's a brand-new feature, will either be a paid-only feature or be  
available to all users but significantly enhanced for paid users  
(higher limits, greater frequency of use, etc). This is to reward  
those people who choose to financially support Dreamwidth.


PRICE POINTS
------------

Our price points for these account types will be:

PAID:
        $35/year
        $17.50/6 months
        $6/2 months
        $3/month

PREMIUM PAID:
        $50/year
        $25/6 months

For the first six months, counting from when we first open our doors  
for account payment, we'll be offering a "thank you for being an  
early adopter" discount. (This is because it costs us less to run the  
site early on, and to recognize the fact that service may be spotty  
from time to time as we work out some of the bugs.) So, our first-six- 
month pricing will be:

PAID:
        $25/year
        $13/6 months
        $5/2 months
        $3/month *

PREMIUM PAID:
        $40/year
        $20/6 months

PERMANENT ACCOUNTS:
        $200, one-time **

* When you get down to payments under $3, PayPal fees get painful --  
see:
http://wiki.dwscoalition.org/wiki/images/8/81/Paypal_fee_percent.png  
-- and therefore we won't be offering a discount on the one-month  
purchase option, since we're using PayPal as our merchant processor  
up front. (Yeah, PayPal sucks, but it's what we know and can  
implement quickly.)

** We will sell 400 permanent accounts at site launch. This will  
almost certainly be a one-time sale -- they'll be on the market until  
400 of them are sold, and then never again. They're priced at the  
same cost of 4 years of premium-paid service.

At any time, if you have a paid account and want to upgrade to a  
premium paid account, we'll convert your basic paid time to premium  
paid time at a 70% conversion rate and add it on to what you buy. In  
other words, if you have 100 days remaining of paid time, and you  
upgrade to a 1-year premium paid account, you'll get 365 days + 70  
days of premium paid service. (We'll round up.) This is to eliminate  
nasty pro-rata calculations, which are annoying for us *and* for you  
and are very hard to explain. (There won't be any way to downgrade  
from a premium paid account to a paid account to stretch out your  
paid time, to avoid people gaming the system.)


BREAKDOWNS
----------

Here is where you can stop reading if you don't care about our  
reasoning for how we set these numbers.

We determined that it will cost us, on average, about $1.40/year to  
support each active user. This is a combination of a lot of factors:  
cost of hardware, cost of bandwidth, cost of salaries (engineers,  
sysadmins, etc), cost of disk space, cost of professional services  
(accounting, insurance), etc.

This is somewhat a voodoo number, because many of these things vary  
based on how many active users we have and what hosting option we  
use. For instance, if we buy our own hardware and colocate, we have  
greater up-front expenses, but our ongoing expenses are lower. If we  
rent dedicated servers, we have much lower up-front expenses, but our  
ongoing expenses get higher and we can support fewer users per cluster.

[Quick digression #1: a "cluster" is a group of machines that band  
together to do all the work of showing you the site -- the database  
backend and the webserver frontend. Colocation means that we can  
support ~200k active users per cluster. Dedicated-server rental means  
we can support ~50k active users per cluster. This is because we can  
buy beefier machines than we can rent.]

This number also assumes that people use their accounts in different  
ways. Some people will post more than others, some people will load  
their reading list more often than others, etc. We worked our numbers  
with a fairly pessimistic assessment of "average use", assuming that  
the site will have heavy transfer use (people transfering data from  
our computers to theirs), heavy disk usage, and frequent load. For  
instance, in our "pessimistic calculations", we're assuming that, for  
instance, people are reloading their reading list between 100-150  
times a day. Obviously, there will be people who do that way more  
(I'm one of them!), and there will be people who do that way less.  
This is why I call these voodoo numbers; we're working on our best  
guess for the level of activity we think we'll get. (We may be  
overestimating or underestimating usage, which is why we built in a  
lot of wiggle room.)

We're also taking expansion capital into account. When we launch,  
we'll be renting dedicated servers. The setup we need to run a single- 
cluster installation (supporting up to ~50k active users), with a  
reasonable amount of data transfer per month that we may or may not  
exceed (our numbers say not, but we'll see), will cost us around  
$5,500 a month. (That's just for the servers + bandwidth -- that's  
not going to be our only expense!) Once we move to colocation, it'll  
cost us around $40k to set up a cluster that will support ~200k  
active users and cost us around $4k a month. (Maybe more, maybe less,  
depending on how much data we transfer.) (There's also the cost of  
initial buildout -- when we *first* move to a colocation solution,  
there'll be a one-time fee for building some infrastructure that will  
serve the whole site. Assume around $60k to initially colocate.)


PERCENTAGES
-----------

Now, the other thing to take into account is that, obviously, not  
everyone will be paying us. Again, we did these numbers a lot of  
different ways. Let's look at a brief overview of some of LJ's  
historical data to have numbers to use (or shoot down):

http://web.archive.org/web/20010413092418/http://www.livejournal.com/ 
stats.bml : The last day that archive.org had saved for LJ's paid- 
account figures, pre-invite-codes. 1.9% of the total userbase had  
paid accounts; 4.2% of users updating in the last 30 days had paid  
accounts.

http://web.archive.org/web/20021014024125/http://www.livejournal.com/ 
stats.bml : The situation approximately 1 year after LJ introduced  
invite codes. 4.8% of the userbase had paid accounts; 13% of users  
updating in the last 30 days had paid accounts.

http://web.archive.org/web/20030801165110/http://www.livejournal.com/ 
stats.bml : This is the last day that archive.org had saved for LJ's  
paid-account figures under the invite code system. 5% of the total  
userbase had paid accounts; 10.5% of active users had paid accounts;  
12.8% of users updating in the last 30 days had paid accounts.

http://web.archive.org/web/20041229233644/http://www.livejournal.com/ 
stats.bml : The last day of Danga ownership, post-invite-code  
removal. 1.7% of the total userbase had paid accounts; 4% of active  
users had paid accounts; 6.5% of users updating in the last 30 days  
had paid accounts.

http://web.archive.org/web/20050423234925/http://www.livejournal.com/ 
stats.bml : The last day that archive.org had saved for when LJ's  
paid-account figures were public. 1.4% of the total userbase had paid  
accounts; 4% of active users had paid accounts; 6.5% of users  
updating in the last 30 days had paid accounts.

We obviously can't know what the current percentages are on LJ, since  
those numbers haven't been public since April of '05.

[Quick digression #2: Some of these numbers and percentages are  
comparing apples to oranges. This is because the definition of  
"active" changed over time, and early on, there wasn't even a spot on  
the stats page for "active". They're good enough for a quick  
estimate, since we're building in wiggle room.]

One other thing to keep in mind: Inactive users (people who aren't  
logging in/loading pages) don't cost us anywhere near as much money  
as active users do. They cost us some, for disk space to store their  
data, but disk is cheap -- it's CPU time and bandwidth that's  
expensive. So, for all of these numbers and calculations, we assume  
that inactive users won't cost us much at all -- we add in an extra  
few cents to the numbers we're working with, for active users to  
subsidize inactive users, but we don't worry much about it.


CALCULATIONS
------------

So, we look at "cost of a user" (approximately $1.40/year for each  
active user) and "percentage of people who will pay for their  
account". We did our numbers at different points: 3% of active users  
paying, 4% of active users paying, 5% of active users paying, etc,  
etc, yadda. (It got even more complex when we added in the "premium  
paid" level, which is our equivalent of LJ's "extra userpics + extra  
disk space" addons.)

We legitimately think that we can, once we hit the level of "mature  
site", reach anywhere between 4% and 5% of active users paid. This is  
pessimistic from LJ's paid account rate at the end of the invite- 
codes-required phase (10.5% of active users), but we're trying to  
avoid being *too* optimistic; we know that it's a bad time  
financially for a lot of people, that we'll be working against a  
considerable network-lockin factor (no matter how much we work to  
make moving to DW as painless as possible), and we'll be dealing with  
having (initially) fewer features than LJ has. (Since some of LJ's  
features aren't open-source, or would cost us way too much, we can't  
use them.)

[Quick -- and somewhat snarky -- Digression #3: Over time we have a  
*lot* of features planned to add to the codebase, based on things  
that people *actually have told us they want* as opposed to things  
that Everyone Else Is Doing. Our feature development priorities will  
be set by what people are actually using the site to do and what  
people actually ask us for, not what Facebook or Myspace or the Hot  
New Social Media Property has added.]

Anyway, the actual calculations we did involve an Excel spreadsheet  
that is much akin to the Shambling Horror of the Deep, involving our  
projected growth rate, our projected paid account rate, our projected  
*premium* paid account rate, our various one-time costs, our various  
ongoing costs, etcetera, spread out over 18 months from a cold start  
(ie, just our initial users), and taking into account various  
potential disasters that could occur at each point. But fortunately,  
if we simplify it down to a basic sanity-check calculation, we get  
about the same answer (which is one of the ways we knew that we had  
the price points correct).

Assume:

* 5% paid account rate, $1.40/active user cost: $28/year
* 4.5% paid account rate, $1.40/active user cost: $31/year
* 4% paid account rate, $1.40/active user cost: $35/year

Taking the most pessimistic of the three options, or the more  
optimistic percentages and adding in some extra padding to cover the  
cost of hardware expansion as we go along, that's our $35/year price  
point for a basic paid account. (The $15 over-and-above for premium  
paid service reflects that we'll be giving those accounts more of the  
features that cost us more money.)


WHAT IF YOU'RE WRONG?
--------------------

Again, we padded the numbers here and there for safety's sake -- that  
$1.40/active user/year includes a couple of cents per user to cover  
the cost of inactive users, for instance, as well as a couple of  
cents into the future-hardware-purchase fund, as well as covering  
salary and overhead for a certain number of staff. (Yes, we're hoping  
to have staff. Ideally, we'd like one paid developer per 100k active  
users. We also need sysadmins, on a contract or salary basis, so poor  
Mark isn't the only one who has to run to the colo facility every  
time something breaks.)

The $1.40/active user also reflects that some things benefit from an  
economy of scale (it's cheaper to do some things for more people)  
while other things don't, and some things depend on how many active  
users we have. Some things are also one-time, while others are  
ongoing. (For instance, hardware purchase, once we move to colo, is  
going to be a one-time cost, while bandwidth is ongoing.)

We may very well be wrong on any one of our assumptions. Things may  
cost more than we're expecting. Things may cost less than we're  
expecting. We may have more users, or fewer, or more paid users, or a  
higher percentage of paid users, or a lower percentage of paid users  
as taken as a percentage of active users, or growth might be faster  
than we expect, yadda.

This is why we're having a permanent account sale at launch: to build  
our operating-capital cushion. We think our first year of operation  
is going to cost us about $80k, so we're selling $80k of permanent  
accounts. If they all sell, and we hope they will, we'll have our  
first year of operating capital in the bank right up front, and can  
concentrate on making a kickass service, applying any additional  
income to building out faster, over that first year. If they all  
sell, *and* people buy lots of paid accounts up front, we'll have the  
capital right up front to move to colocation before we're even out of  
open beta, which will save us a lot of money and trouble in the long  
run (but costs more to get set up). If they don't all sell, well,  
we'll cross that bridge when we come to it. :)


WHERE WILL THE MONEY GO?
-----------------------

Our first priority is, obviously, building the infrastructure we'll  
need for the service at launch and paying the month-to-month  
operating costs. After that, and for the first year or two, we'll  
probably be adding staff as we can afford them, as well as building  
out our infrastructure to keep up with site expansion.

After that, our Operating Agreement specifies how the profits (if  
any) are to be distributed:

* First, into a six-month operating cost fund, to be kept liquid or  
semiliquid on hand at all times, then:
* 1/3 directed to benefit the community as determined by the Members  
of the LLC (currently: Mark and Denise);
* 1/3 directed to benefit the community as determined by members of  
the community (through a process to be determined later);
* 1/3 distributed to the Members of the LLC as profit.

( http://wiki.dwscoalition.org/notes/Operating_Agreement )

This is, we think, the best balance between wanting to reinvest in  
the community and wanting to have fiscal motivation to bust our asses  
to make Dreamwidth succeed. If we get rich off this, the Dreamwidth  
community will get twice as rich!

[Quick digression #4: No, we don't yet know the process by which the  
community will be able to determine the application of profits, but  
we do reserve veto power in the Operating Agreement, which means that  
we'll vet proposals before they reach the community for voting. "Send  
all the profit to Joe Smith" won't make it to the voting point. "Use  
this money to drop the price of a paid account by $10 for the next  
fiscal year" would. People could then decide what they want to spend  
the community's money on: more staff, paying for the implementation  
of specific features, etc, etc. We'll work that all out down the road.]


I know this is long, but I know a lot of people are *really*  
sensitive about the idea of anyone benefiting from their creative  
work as is so common in this Web 2.0 world, and we want to give you  
guys as much transparency into our finances and thought processes as  
possible. I also expect that people will have a lot of questions  
about what's gone into this email, so I ask one favor:

*Please* read the followup emails in this thread before you ask your  
question! I'll answer questions as they come in, as I can, and then  
I'll round up all of my responses to those emails and add them in as  
links to the Business FAQs section of the Wiki as I can. When we  
launch, we'll rewrite all of those into information that can appear  
on the site for people who haven't been following the discussion from  
the beginning.

--D



-- 
Denise Paolucci
[email protected]
Dreamwidth Studios: Open Source, open expression, open operations.  
Coming soon!

_______________________________________________
dw-discuss mailing list
[email protected]
http://lists.dwscoalition.org/cgi-bin/mailman/listinfo/dw-discuss

Reply via email to