Paid Accounts
Because we are committed to maintaining a stable, reliable service without ever accepting third-party advertising, we rely on subscription fees from our users to help us meet our operating costs. In exchange for those subscription fees, we offer additional or expanded services and features to our paid users as a way of saying thank-you for subsidizing the service for everyone else. We also reserve the features that cost us money to offer, or that cause significant database or webserver load, for users who have purchased paid accounts.
All of our assumptions, spreadsheets, cost projections, and business plans were done at a 5% paid account rate: each paid account will subsidize 19 free accounts. This applies whether the paid account is for a month or a year. Every payment someone makes will help pay for our servers, our bandwidth, necessary professional services, and the salaries and contractor payments we will be making to those who help develop and run the site.
We project that it will cost us approximately $1.40 a year to support each active user.
Features are reserved for paid contributors for two reasons:
This means that some features are reserved for paid users because they're expensive, and some features are reserved for paid users because they're popular. (Sometimes, it's both.) For features that have limits, we offer higher limits to those who choose the Premium Paid account level. This reflects the fact that offering higher levels of these features costs us more money.
As we create new features, we plan on doing it two ways. Some features will be entirely reserved for paid users. Some features will be available to everyone, but significantly enhanced for paid users. We want to strike the right balance between rewarding people who've chosen to subsidize the service for everyone else, and making the service useful and functional for members of all levels.
We know that we likely won't get it completely right on the first try, especially since many of the paid user features on LiveJournal.com aren't available to us to use (either because LiveJournal's implementation of the feature isn't Open Source, because offering that feature would require expensive external partnerships, or because we don't think the implementation LiveJournal chose was the best way of doing it). During our first year of operations, we will constantly examine the paid user features and see what we can add.
Here's a list of the paid user features that will be present at open beta launch (along with why they're a paid user feature). Right now, you can see the Account Levels wiki page; we'll move that information onto the site before we launch to open beta, as we get our payment system finished.
There are two things that LiveJournal reserves for paid users that we allow every personal account (ie, not OpenID accounts) to do, because we think they're such critical and useful functions of the site that all users should be able to do them. Those things are:
In our first year of operations, we'll be adding a number of features that are either paid-user-specific, or are significantly enhanced for paid users. Right now, the plan includes any or all of the following:
We will also be working to create better features for paid communities, under the same theories: anything that costs us money to offer, anything that puts a strain on our servers, and some things that are just plain nifty will be reserved for paid communities, while anything that significantly enhances the community experience and doesn't cost us much to offer will be available for all communities.
All of our assumptions, spreadsheets, cost projections, and business plans were done at a 5% paid account rate: each paid account will subsidize 19 free accounts. This applies whether the paid account is for a month or a year. Every payment someone makes will help pay for our servers, our bandwidth, necessary professional services, and the salaries and contractor payments we will be making to those who help develop and run the site.
We project that it will cost us approximately $1.40 a year to support each active user.
Features are reserved for paid contributors for two reasons:
- Because offering the feature costs us more than a few cents per user per year;
- As a way of saying "thank you" to users who have chosen to support the site, and other users, financially.
This means that some features are reserved for paid users because they're expensive, and some features are reserved for paid users because they're popular. (Sometimes, it's both.) For features that have limits, we offer higher limits to those who choose the Premium Paid account level. This reflects the fact that offering higher levels of these features costs us more money.
As we create new features, we plan on doing it two ways. Some features will be entirely reserved for paid users. Some features will be available to everyone, but significantly enhanced for paid users. We want to strike the right balance between rewarding people who've chosen to subsidize the service for everyone else, and making the service useful and functional for members of all levels.
We know that we likely won't get it completely right on the first try, especially since many of the paid user features on LiveJournal.com aren't available to us to use (either because LiveJournal's implementation of the feature isn't Open Source, because offering that feature would require expensive external partnerships, or because we don't think the implementation LiveJournal chose was the best way of doing it). During our first year of operations, we will constantly examine the paid user features and see what we can add.
Here's a list of the paid user features that will be present at open beta launch (along with why they're a paid user feature). Right now, you can see the Account Levels wiki page; we'll move that information onto the site before we launch to open beta, as we get our payment system finished.
- Icons: We'll likely be able to raise our icon limits once we see what our usage looks like, but icons are the number one most expensive thing that we offer, because they're stored and used in so many places on the site.
- Inbox tracking subscriptions: Tracking someone's posts, comments to posts, or other things that can be tracked is resource-intensive; sending email only costs us a couple fractions of a cent, but the real cost is in the processor power necessary to see who's tracking that item and who should get notified.
- Special subscriptions: We also reserve some subscriptions for paid users only, like being notified when someone posts a poll or when someone in your circle uploads a new userpic. This is a combination of the fact that those subscriptions are computationally expensive and the fact that those subscriptions are nifty.
- Subscription/access limits: We have to put limits on how many people you can subscribe to or grant access to because building the reading page and determining who's authorized to see which posts is computationally expensive. Paid users get higher limits.
- Number of tags you can use: We have to put limits on how many tags you can use in your journal because building the tag list and determining what tags each post uses is computationally expensive. Paid users get higher limits.
- Expand comment threads: Inline expansion of comment threads with the 'expand' link is both computationally expensive and adds to our bandwidth burden, so we reserve it for paid users.
- Fast Lane: When the site gets overloaded, it can be slow for everyone. We're putting in a function that will let paid users' requests "jump the queue", and be processed before free users' requests. Our goal is to make the site fast for everyone, but when we're having high traffic, that way paid users get to go to the head of the line.
- Receive forwarded email at @dreamwidth.org: Processing and sending email costs us a couple fractions of a cent, but mostly we reserve this for paid users because it's nifty. (And we do have plans on how to fix up the spam problem.)
- Mass-change privacy: The function to go back in your journal and set all old entries to a different security level is computationally expensive, so we reserve it for paid users.
- View your journal entries by security level: The function to view older entries in your journal by security level (so, "all posts to this filter" or "all posts I've made to my access list") is computationally expensive, so we reserve it for paid users.
- Network page: Building a page of the people who are read by the people you read is computationally expensive, so we reserve it for paid users.
- Forward your domain to your journal: This feature doesn't cost us much, but we save it for paid users because it's nifty.
- Post polls: This feature doesn't cost us much, but we save it for paid users because it's nifty.
- Create mood themes: This feature doesn't cost us much, but we save it for paid users because it's nifty.
- Receive copies of your own comments in email: This feature doesn't cost us much, but we save it for paid users because it's nifty.
- Receive text messages through Dreamwidth: This feature doesn't cost us much, but we save it for paid users because it's nifty.
- Ability to use Google Analytics in your journal: This feature doesn't cost us much, but we save it for paid users because it's nifty.
There are two things that LiveJournal reserves for paid users that we allow every personal account (ie, not OpenID accounts) to do, because we think they're such critical and useful functions of the site that all users should be able to do them. Those things are:
- Creating syndicated feeds: All users can go to the syndication page and create feed accounts. It costs us money to transfer that data and to run the process that checks for updates, but we thought it was important enough for our ideal of cross-site interoperability to let everyone do it.
- Directory search: All users can use the Directory to find other users in their area or by interest. It's computationally expensive, but we thought it was important enough for our goal of letting people find other people who make the kind of content they like to read. (Note for closed beta: the directory's currently broken -- that's a bug, and we'll be fixing it before open beta.)
In our first year of operations, we'll be adding a number of features that are either paid-user-specific, or are significantly enhanced for paid users. Right now, the plan includes any or all of the following:
- Scheduled posts: The ability to write posts ahead of time and have them post at a specified date. All users will be able to use it; paid users will have a higher number of scheduled posts they can queue up. The higher limits will be a paid user feature because it will cost us to store the posts.
- Draft posts: The ability to write posts ahead of time and save them as drafts, so you can come back and finish them later. All users will be able to use it; paid users will have a higher number of draft posts they can store. The higher limits will be a paid user feature because it will cost us to store the posts.
- Export journal as .pdf: This will let you save your journal contents as a .pdf file, for both backup and printing. All users will be able to use it; free users will be limited in the number of times they can do it, because it's computationally expensive, while paid users will be able to generate .pdf files more often and with more specific criteria (such as by tag). The higher limits will be a paid user feature because it will be computationally expensive.
- Expand all comments on page: This will be paid-user only, and will allow people to expand all comments on a single page of comments. It's going to be a paid user feature for the same reason the thread expander is paid-user feature: it's expensive both computationally and bandwidth-wise.
- Bookmarks views: We're planning on changing 'memories' to 'bookmarks', and making it function much like Delicious does. All users will be able to bookmark things (both publicly and privately) and see others' public bookmarks; paid users will likely be able to see the aggregate public bookmarks of the people on their reading list and the people in their network (those who are read by the people on their reading list). This part of it will be a paid user feature because it will be computationally expensive.
- Image hosting: We will be creating some method of image hosting, which we will design based on your feedback. It will likely be a paid user feature, because it will cost us both for disk space to store the images and bandwidth to serve them.
We will also be working to create better features for paid communities, under the same theories: anything that costs us money to offer, anything that puts a strain on our servers, and some things that are just plain nifty will be reserved for paid communities, while anything that significantly enhances the community experience and doesn't cost us much to offer will be available for all communities.
Page 1 of 2