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

Revision as of 10:38, 17 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?

One question we're hearing frequently: why is Dreamwidth not a nonprofit or member-owned collective? Since we talk so much about community sense-of-ownership and empowering the Dreamwidth community to help us make decisions for the direction and function of the site, and since we promise so much transparency in our financial and business dealings, why not set up a 501(c)(3) to ensure and enforce that transparency and openness?

We thought long and hard about organizing as a 501(c)(3) when we first embarked upon this journey, and eventually (and reluctantly) discarded the idea after significant research into the feasability. There are three main reasons why a nonprofit or member-owned collective wouldn't work for us up front:

• The administrative overhead isn't conducive to the kind of small, tightly-focused business we want to run. Running a nonprofit is an insane amount of effort that we feel is better put towards making a kickass product. Starting up and administering a nonprofit is a full-time job, and requires very specialized accounting and accounting experience. We think that kind of effort is best focused elsewhere.

• Legally, a 501(c)(3) organization is prohibited from any lobbying or political action. While we don't intend to ever participate in mainstream political issues as a company -- Mark and Denise are nearly 180 degrees from each other on the political spectrum and often have to agree to just not mention politics anywhere near each other -- we do want to be active, down the road, in political advocacy when it comes to proposed legislation that threatens the right of free expression on the Internet. If we organized as a 501(c)(3), we couldn't rail against clueless legislators who don't understand what the Internet is but yet are trying to control it -- or our ability to do so would be seriously curtailed. We believe passionately in the right of free expression on the Internet, and we don't want to do anything that might inhibit our ability to lobby against such misguided legislation as has already been attempted.

• Finally, a practical matter: a 501(c)(3) cannot remove someone from membership for any reason other than nonpayment of dues. This would tie our hands in very significant ways when it comes to fighting abuse on the service, and prevent us from taking certain actions. For instance, if someone had paid for membership on the site, and then posted material that opened Dreamwidth up to legal liability (such as child pornography), or incurred multiple substantiated reports of copyright violation (which, by US law, must result in the removal of the user from the site), we would be unable to take the action required by law without violating another law.

There are possible solutions to all of these issues, but none of them are easy, and solving all of them would have taken significant time and effort away from the process of developing Dreamwidth. We know that a lot of people are uneasy about the profiteering nature of Web 2.0, and are very uncomfortable with the idea of someone else profiting from their creative effort. This is why we're very committed to being as open and transparent as possible, so people can always examine our motives and our actions and decide where their own comfort level is.

We care very much about creating a service that's focused on pleasing our users, not investors, venture capitalists, or advertisers. We don't have investors, venture capitalists, or advertisers to please. And while we can tell you right now that we're not in this to get big and sell out, we know people have been burned before by people who have said the same, so all we can say there is: we hope that, over time, we can earn your trust.

You can read our Operating Agreement, the legal document which covers Dreamwidth Studios, LLC's operation and functioning, and as we build and run the site, we'll tell you as much as we can about the details of our day-to-day operations. While we won't be bound to the same accounting standards as a 501(c)(3) would be, in terms of financial disclosure, we hope to strive for the same level of financial transparency on a voluntary basis.

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 are accounts going to cost what they cost?

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

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

We set our price points to cover the assumption that between 4-5% of active users will be paid users of some fashion (which is in accordance with the old LJ statistics). After adding up all of our costs, we determined that it will cost us approximately $1.40/year to support a single user (on average). So, we multiply:

• 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

Assume the pessimistic percentage, or assume the higher percentage and add in some extra padding to cover the cost of hardware expansion as we go along, and we set our "basic paid" price there. Our "premium paid" level is to allow people to purchase higher limits, which cost us correspondingly more.

This is an incredibly simple answer. The longer answer involves lots of numbers and covers our operating assumptions in detail.

We will be discounting our paid accounts for the first six months of operation, both as a "thank you" and to reflect the fact that our costs will be lower earlier on in our site operation.

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.