Dreamwidth.org: Business FAQs

Expand: This FAQ still needs to be filled out by those in the know.

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

For more information, please see our Diversity Statement which talks a bit more about the kind of people Dreamwidth is designed for. But here's a hint: it's designed for you.

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 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)?

No.

Mark and Denise both worked for LJ for years, and both of them left at various points to pursue other opportunities, but both of them always loved LJ both for what it was and what it could be. They were talking as early as 2004 about creating a technical and social fork of the code; Dreamwidth is their attempt to capture all of the things that made LJ so awesome, while at the same time fixing a lot of the issues (both technical and social) that they identified over the years and incorporate the lessons they learned from other social media properties -- both good and bad.

Dreamwidth isn't a reaction to any single decision that LiveJournal has made, or will make, or has proposed. Likewise, we aren't trying to define ourselves as "not LJ". We used the LJ code as our base, because it's what we know and are familiar with, and because it's what our ideas for improvement were founded in -- there's so much potential in LJ's features and functions, many of which pioneered many "Web 2.0" social-media features that are now in widespread adoption. Sadly, many of those features were bogged down by poor implementation, poor usability, or an unclear vision for the overall function and future of the site.

What we're doing with Dreamwidth is going back to all of our ideas about what a good online community should be, reasoning from what we've seen work and what we've seen fail. We're taking the LJ codebase (because, again, it's what we know) and working from there. Our goals are entirely different from LiveJournal's, and our target demographic is, as well. We aren't trying to go head-to-head with them. We're carving out our little niche, and we're sticking to it.

Dreamwidth is for people who want to create things: words, art, photographs, or just a record of your life. Dreamwidth is for people who want to build an online community, for people who want to come together and learn from each others' experiences, each others' lives, and each others' thoughts and hopes and dreams.

You can read our Guiding Principles and Diversity Statement to learn more about who and what we are as a company, and what our vision for Dreamwidth is. We aren't doing this as a reaction to anything. We're doing this because we believe in the power of online community, and we believe that what we make here can be interesting, useful, valuable, and relevant to people from all walks of life. We want to build a place where you feel welcomed, valued, and cherished as individuals and as a community -- while having fun putting it all together.

We're pretty confident we can make it work.

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

(For a quick overview of opt-in vs. opt-out, check here.)

Every time a new change or feature was rolled out on LJ, the first question was always: why can't you make this opt-in? (In other words: why is the default for any new feature or behavior "on", with people explicitly having to turn it off?)

The answer to this is, in essence, that it's impossible for any site to reasonably reach all its users (such as with announcements of new features) in a timely fashion, unless that site wants to use methods such as mass email (which is a bad plan for oh so many reasons). New features, or changes to existing features, when coded, are coded for a reason -- it's because the site administrators have identified a need that isn't being handled properly, and they want to fix it.

So, there's no good way to communicate "hey, we have this change available", and even if there were, a lot of users probably wouldn't try the new change/feature to see whether or not they like it. Obviously, a site's owners code something because they think that the change is beneficial to the long-term health of the site, so there's always an incentive to get people to use or adopt it. By just going ahead and changing it, it lets people know that the change is available, and if an opt-out is offered, people who really hate the change can opt out of using it after they've tried it and decided that it doesn't work for them.

Now, there are always people who are resistant to change, and it could be for many reasons -- maybe the change happens to totally break how they're using the site. (This is the most common reason; there are a lot of different use cases for anything as complex as a site this far-reaching, and people adapt tools to the weirdest purposes.) Or it could be something as simple as people getting annoyed at having to retrain their "muscle memory" to look for things in a different place.

There are really two major categories of change that people would like an opt-out for: visual/aesthetic changes (a redesign of the page), and a new feature that changes their interaction with the site (and they don't like). (This all goes back to the discussion in the link above, about the "logged-in viewer" vs "journal owner" control paradigm and the (badly-handled) intersection between the two.)

It's easy to offer opt-out options for features, and we'll be careful to both design and release any new feature with a careful eye to how to instruct people to turn it off (if the answer turns out to be more complex than just "don't use the feature".) The issue comes when we have to redesign a feature, either aesthetically or functionally, and remove or radically restructure the old behavior. (Examples would be like when we totally gut and redo the Memories feature, which is badly in need of an overhaul.)

In situations like that, where we're making sweeping changes to an old feature, it's simply not possible to offer an opt-out and allow people to continue using the old version. The reason for that is that maintaining two (or more) separate versions of the code is a drain on programmer time and resources, which are better spent elsewhere on adding new features.

So, basically, Dreamwidth's model works like:

• If a change is aesthetic or workflow-based, to fix the usability of a particular page or feature, there likely won't be an opt-out (a choice to continue using the old version of the page), because maintaining two separate versions of a page is time-consuming and a poor use of programmer resources.

• If a change is an entirely new feature, we'll release it with a careful eye towards privacy, security, and user customizability, so people can choose on their own whether they want to be affected by it or not (and not use it, or opt out of being included in it, etc, as they prefer)

• We'll release all of our changes with advance notice and clear instructions for how to set your preferences. (In fact, we'll be soliciting user feedback from moment one of design.)

• No matter what, we will always tell you why we're making a change, what problems the change is intended to solve, and why we think it's a necessary change, so you know the problem that we've identified and are trying to fix. That way, if anyone can come up with a fix for the problem that's better than our proposed fix, we can change our plan before the change is released.