Difference between revisions of "Dreamwidth.org: Business FAQs"

Revision as of 01:42, 16 January 2009

Commonly asked questions about dreamwidth.org's business operations and business plans, so we can have them in one place and point people at them when they come around again on the gee-tar. These aren't questions and answers that are designed for eventual inclusion on the site, but things that are coming up (or will be coming up) on the mailing lists during the construction and beta phase, so as to save everyone's sanity and prevent yet another go-around on the specific topic.

Some of these answers are links to where they were previously answered on the mailing list, while some of them have never been written up in one place but have been scattered through various threads. (In that case, we'll synthesize all the various bits of answers into one answer here, or write the email to the mailing list and then link it here.)

Why aren't you organized as a nonprofit?

Why won't you let us design our own paid accounts/only pay for what we want/add things a la carte?

For both technical and social reasons, we've chosen to offer two levels of paid account, at two different price points, with the same features but different limits to each. While it's possible this may change in the future, it's highly unlikely. (Followup explanation)

Is Dreamwidth a fandom-based project?

Dreamwidth is not fandom-specific, but is fandom-friendly.

What do you plan on doing with the profit from Dreamwidth?

Our Operating Agreement, the legal document that governs how Dreamwidth Studios, LLC must be run, specifies the distribution for any profit that dreamwidth.org makes. (Profit is, of course, defined as any capital intake over and above the expenses incurred in running the site, including hardware cost, hosting fees, bandwidth, salaries, insurance, overhead, etc, etc.)

The first thing that the Agreement specifies is that we have to keep a six-month "operating fund" liquid or semi-liquid at all times before any other distributions are taken. This is to ensure that we have sufficient capital to keep the site running. (We define our operating expenses as what it costs to run the service at current capacity, plus capital to cover our projected expansion, plus some wiggle room for emergency hardware purchases and other unexpected disaster.)

Over and above that -- although we don't expect to reach this point for quite some time, as we do plan to invest all of our income back into site development, whether through purchasing additional hardware or through adding additional paid staff -- the Agreement specifies that any profit the site makes should be distributed as follows:

• 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.

We thought about this for a long time, and this is the solution we came up with to the problem of both wanting to have a binding commitment to reinvesting in the community we're building and wanting to have fiscal motivations to bust our asses to make Dreamwidth succeed.

In short, we don't ever expect -- or really even want -- to get über-rich on this. We want to earn enough to support ourselves and our families, and use the rest to nurture and support the community and the project. Both of us are passionate about online community, and we want to build a good one. We're going into this with the idea that Dreamwidth isn't going to be the next Facebook or Myspace; we're always going to be the family-owned business down on the corner of the neighborhood. Our goal is to build a sustainable, long-term business that will be here for a long time. We're both prepared to make this something we'll work on for the rest of our careers, and we're designing for that from the ground up.

Why aren't permanent accounts going to always be on sale?

Permanent accounts are a good way for a site to gain a much-needed infusion of cash from time to time, such as when new hardware purchases are being planned or when a site begins its operations. The problem with selling permanent accounts, though, is that it's a balancing act: you're trading off revenue in the future for cash-on-hand now. Once someone's purchased a permanent account, they may continue to financially support the site in the future through things like purchases of paid time for friends, merchandise, additional add-ons such as virtual gifts and gift certificates, etc, but that income isn't guaranteed.

For a site that's looking to maximize its short-term profits, or make up for budgetary shortfalls right now, having permanent accounts on sale can be beneficial -- but for the long-term health of the site, they're a bad idea, since they privilege short-term revenue over long-term sustainability, even if the cost of a permanent account is set to be greater than the average length that someone's likely to maintain a paid account. (This is because the people who are willing to pay for permanent accounts are more likely to be passionate, long-term users who would otherwise be a steady source of income, and thus operating capital, for a site.) If a site sells too many permanent accounts, they'll have a lot of money in hand now, but once that's spent, it's spent, and if too high a percentage of the potentially-paying userbase has permanent accounts, they'll be facing shortfalls down the line.

Permanent accounts are bad for users, too, because it strips users of their ability to influence site operations with the most important thing possible: voting with your pocketbook. A site that already has your money doesn't have to work to keep you happy, because they don't have to worry about keeping your business. We don't want anyone to ever feel like we're ignoring them because they're a "safe bet" -- we plan to do our absolute best to make every single user of the site feel like a valuable community member, and we want to minimize the chance that anyone could possibly feel like they're not being listened to. We are here to serve you, the Dreamwidth community and the Dreamwidth users, and we aren't here to grab your money and run.

Because we're building Dreamwidth with an eye towards long-term sustainability, we don't plan on offering permanent accounts for sale except once, at site launch, to build our initial operating fund. Circumstances may change down the road and make selling permanent accounts a more attractive option, but we highly doubt it. We'd rather build a kickass product and make you want to support us that way, and we'd much rather have a slow, steady, and reliable income than quick bursts of cash here and there. That's the way to design a healthy business, and one that will last.

Are you going to translate the site into other languages?

Most likely not. Certainly not at launch, and almost certainly not after that, unless we can solve some particularly difficult problems (as enumerated in that message).

Why are accounts going to be so expensive?

Why don't you have all the features LJ has, if you're based on the LJ code?

In some cases, we don't have the features that LJ has because LJ has chosen to make that feature non-Open Source. (LiveJournal has certain features that go into their non-Open Source code repository; legally, we cannot use or redistribute that code.) Examples of these features include Voice Posting, several journal layouts, details of the payment system, etc.

In some cases, we've evaluated the features and decided that they don't fit what Dreamwidth wants to do. (An obvious example of this: advertising.) This includes things like removing Snap.com graphical previews. (It also includes retooling the Adult Content system: we're keeping the option, in case people want to use it for their own journals, but we're removing the ability for one person to report another's content that way, and we've cleared up a lot of the confusing nomenclature and design around the function.)

In some cases, the feature itself was never truly finished on LJ, and we've determined that it's better to remove it from our code entirely and redo it from scratch than to try to fix the very, very broken behavior as it stands now. (One likely example of this: the to-do list.) While we might not remove them from the code entirely by launch, we will rip them out at some point and replace them with a much better version. For instance, we're going to completely redo the Memories function, which hasn't been touched (code-wise or usability-wise) in about eight years.

And finally, the fourth case of things are features that cost a lot of money to offer, or require partnership with third parties or dedicated hardware that we just can't support at launch. Examples of these include Voice Posting and TxtLJ: voice posting requires dedicated hardware and partnerships with VoIP providers, and TxtLJ (interacting with the site via SMS) requires a very expensive SMS shortcode purchase, conformity with very exacting wireless carrier regulations, and expensive SMS charges. These are features that we may offer somewhere down the road, if the site's economics ever support them and there's sufficient user demand, but currently, we aren't planning on it.

We're keeping a list of things we won't have at LJ features not in Dreamwidth.

Is this all just a reaction to (latest LJ decision)?

Why can't all these changes be opt-in?