denise: Image: Me, facing away from camera, on top of the Castel Sant'Angelo in Rome (Default)
Denise ([staff profile] denise) wrote in [site community profile] dw_biz2009-04-09 11:15 pm Business FAQs

Welcome to [site community profile] dw_biz, where we'll make regular posts about the business operations of Dreamwidth Studios, LLC, the company that runs We'll use this to talk about the reasoning behind our business decisions, tell you about what we're doing, answer your questions about our operations, and generally keep you informed.

Posting to [site community profile] dw_biz will be limited to Dreamwidth's owners and staff, but anyone can subscribe to the community and make comments to posts.

For our inaugural post, I figured I'd provide answers to some of the common questions we've been hearing. (Many of these questions and answers come from the Business FAQs list that we kept on the Wiki up until now, but I wanted to move them into [site community profile] dw_biz for posterity's sake.)

Operating Structure

What is your operating structure?

Dreamwidth Studios, LLC, is a Maryland-based Limited Liability Company. You can read our Operating Agreement, which is the document we filed with the State of Maryland to form the company.

Why did you form a for-profit company instead of a non-profit or member-owned collective?

We thought long and hard about organizing as a 501(c)(3) (nonprofit) when we began thinking about creating Dreamwidth, 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 lobbying or political action. While we don't intend to ever participate in mainstream political issues as a company -- [staff profile] mark and I 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 would have to carefully follow a number of guidelines regarding lobbying. 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, 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.

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.

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

Our Operating Agreement specifies the distribution for any profit that 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: [staff profile] mark and myself);
  • 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.

What if you get tired of running the company?

A question we've heard several times: what if you get tired of running the site and want to quit? How will you make sure to provide for the community, and make sure that your vision for the site can be upheld?

Our Operating Agreement contains provisions for this situation:

7.1 ASSIGNMENT. If at any time a Member proposes to sell, assign or otherwise dispose of all or any part of his interest in the Company, such Member shall first make a written offer to sell such interest to the other Members at a price determined by mutual agreement. If such other Members decline or fail to elect such interest within thirty (30) days, and if the sale or assignment is made and the Members fail to approve this sale or assignment unanimously then, pursuant to the Maryland Limited Liability statutes, the purchaser or assignee shall have no right to participate in the management of the business and affairs of the Company. The purchaser or assignee shall only be entitled to receive the share of the profits or other compensation by way of income and the return of contributions to which that Member would otherwise be entitled.

(Emphasis for purpose of this discussion.)

Right now, there are two Members of the LLC that own the site. With two of us, there's a greatly reduced chance that both of us would want to sell at any given time, and the Agreement says that if we do, we have to sell our share in the company to the other person first. (That person could then allow someone else to buy into the LLC by selling them a percentage of their share.) If the other person decides that they don't want to (or don't have the capital to) purchase the other person's share of the company, and the selling member sells their share to someone whom the non-selling member thinks won't make good decisions for the company, the remaining owner does not have to allow that new owner to participate in the management decisions of the company.

(So, if I sell my share of the company to somebody evil, Mark doesn't have to allow that person to make decisions about how the company's managed, and vice versa.)

Basically, our operating agreement separates the concept of site management and LLC ownership. If one or both of us decides that we're burned out on day-to-day site management tasks, we can appoint someone else to do daily management, but as owners of the LLC, we still retain final veto to override things. If one of us wants to get out entirely, that one has to sell to the other before selling to a third party. And if that person does sell to a third party, the remaining "original" member is not required to allow that person any right to make decisions for the site management or the LLC itself.

(Yes, we know this doesn't quite address the scenario about what happens if both of us want to sell our interest in the company to someone else, either right now or down the line, but because site management and LLC ownership is so divorced, we both reasonably feel that there's less of a chance of that. We both agree that if one of us is frustrated and burned out on the day-to-day running of the site, we'll employ someone to do our role for a while and step back to only be involved in major decisions, rather than sell our interest in the company.)

What steps are you taking to ensure continuity of administration?

We've been calling this the "hit by a bus" plan -- what happens if [staff profile] mark or I get hit by a bus?

As we've been creating Dreamwidth, we've been cross-training each other, and training volunteers, to do the tasks we do regularly, and to make sure that no one person has all of the knowledge about a specific issue, system, or task. Our eventual goal is to reach triple redundancy in terms of organizational knowledge: every task being performed by one person should have two other backup people who know everything that needs to be done.

Obviously, since we're still in "startup" mode, we haven't quite gotten there yet -- but we're working on it.

Account Types and Costs

Why will accounts cost what they cost?

We set our account prices by looking at several things: the price of server rental or purchase, the price of bandwidth, the price of storage, the price of staff (judging by experience, we know that we'll need one full-time developer for roughly every 100,000 active users, one full-time sysadmin for roughly every 150,000 active users, one full-time customer service person for every 300,000 active users, etc), the price of professional services such as accounting, insurance, and legal advice, the price of equipment, etc. When we ran the numbers, we came up with a "cost per active user" at around $1.40 per year per active user: that's what it will cost us to provide service to one active user.

We set our price points with the assumption that we'll be able to achieve a paid account rate of between 4.5% and 5% of the userbase, which we arrived at by looking at the historical record of paid accounts on and adjusting downward for the fact that we're a newer service and will (at least initially) not have all of the paid account features available on LiveJournal. (We'll have different paid-account features as we're able to spend time developing them, though.)

If you're interested in seeing our reasoning for how we set our paid account prices, you can see a mailing list message in which I got into further detail.

Will Dreamwidth always require invite codes?

At this moment, there are no plans to ever remove the invite code system.

The reason for this is simple: We want to control our growth to make sure that we're not growing faster than we can support. If we don't have enough hardware to render and run the site, it will be slow for everyone, and slow site performance makes us make sad faces. By requiring people to have an invite code to join the site, it will allow us to keep a careful eye on site performance and make sure that we're not growing faster than we can support.

We know that many people find invite codes to be a very limiting factor, and we know that it can leave people feeling that a service is elitist or unwelcoming. We plan to address this through multiple things:

  • We will be very, very generous with the number of invite codes we give out to our existing users to distribute. We want our users to be able to invite their friends -- we don't want people to feel like they have to hoard their invite codes for later use.
  • If you want to create an account, and you don't know anyone with an invite code, you'll be able to buy a paid account. Even the one-month paid account option (for $3 USD) will be enough to create the account, and if you choose to let your paid account expire, you'll still be able to use it as a free account.
  • We've opened [site community profile] dw_codesharing, both for people who have invite codes to distribute and people who are looking for invite codes for themselves.
  • We've done a lot of work in cleaning up our OpenID support, so people who just want to maintain a reading list and leave comments to others' journals won't need a Dreamwidth account to do it.

How will invite codes be distributed?

On a regular basis (every two weeks or every month), [staff profile] mark and I will look at a bunch of factors: how many active users we have, what our paid account rate looks like, what our paid account churn (people who choose not to renew their accounts) looks like, what our network performance looks like, what our hardware performance looks like, what our operating fund's balance is, etc. We'll determine how many new free users we can support that month, and distribute the appropriate number of invite codes.

We can automatically distribute those invite codes in a number of different ways: we can give them to people who have paid for their accounts, people who have used up all their invites, people who are active, people who have invited other people who have gone on to be active, etc. We're likely to use any and all of these methods for distribution as time goes on, to see what sort of results we get from each distribution method.

We will, at all points, release as many invite codes as we feel we can.

Why will Seed (permanent) accounts not regularly 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.

Why can't I design my own paid account or pay for features a-la-carte?

For both technical and business 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.)

We may, in the future, allow people to purchase additional icons or additional disk space (once we offer photo hosting) as add-ons for their account. However, we will most likely never allow people to purchase those add-ons without a corresponding paid account. The price of paid accounts, and what features and options those paid accounts get, are set based on the assumption that not every user will use all of the features at the maximum allowable rate; there is a certain degree of "overselling" assumed in the paid account structure, and allowing people to purchase add-ons without purchasing paid account time would disrupt that balance.

We may be able to solve the problems someday, but it will take a lot of careful consideration and scrutinizing of our statistics, so it's not something we'll be able to do quickly.

Feature Design

How will you design new features?

When we are designing new features for the site, we will incorporate user feedback as much as possible. The process will work something like:

  • We'll post an entry (to whatever community we use for this purpose) describing the feature and what we want it to do, what we hope to accomplish with it, and what we consider absolutely necessary for it. We'll ask you to leave comments with what you would want to see from a feature like that -- and, more importantly, what you wouldn't want it to do.

  • Once we've gathered feedback, we'll write up the functional spec for the feature, which will describe everything the feature must do, should do, could possibly do, and "would be nice if" it did. We'll post that spec, and have another round of discussion, where we ask you if we've missed anything, if anything should be a higher priority, if we've forgotten to think of anything, etc. We'll address anything that we can't include, or anything where people have asked for mutually exclusive options, and explain why we've chosen the things we've chosen and why we can't include the things we've left out.

  • We'll turn the spec over to whoever's doing the frontend design for that feature, and ask them to provide the mockups of what that design should look like. We'll post those mockups and ask you to leave comments with any problems you see or things you'd like to see changed.

  • Once we've gathered feedback, we'll do a second draft of our design, and post that. We'll address anything that we can't include, or anything where people have asked for mutually exclusive options, and explain why we've chosen the things we've chosen and why we can't include the things we've left out.

  • We'll turn the spec and the mockups over to the programmer who's programming the feature, who will implement it.

  • Once it's been implemented, we'll turn it over to our testing team, who will test the functions and find any major bugs or problems with it.

  • Once our testing team has signed off on the feature, we will include it in the next code release.

Will new features be opt-in or opt-out? Can I continue using the old version of a page?

(For a quick overview of opt-in vs. opt-out, check a mailing list discussion from last August.)

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). 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, our 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, as seen above.)

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

Site Content

What restrictions do you place on content?

As our Guiding Principles state, we place the minimum restrictions possible in order to remain compliant with United States law (since we're a US company) or to protect the health and viability of the service (such as removing spam).

We know that this is a very nebulous statement, and that people have specific questions about what sort of content is permitted and what isn't. We're working on providing answers to those specific questions, as well as providing our Terms of Service enforcement policies.

Overall, though, we believe in free expression to the maximum amount allowable by law, and we're willing to fight for it. In exchange, we ask that you try your best to make it so that we don't have to, by exercising discretion in using privacy settings and age warnings as appropriate on material that's not illegal, but that other people might find questionable. We will never make you do it, but it'll make everyone's lives easier.

Can you tell me more about what sort of situations you'll take action in?

We don't want to make an exhaustive list right now, because the best we could do would be to reason from our experience with other social websites. While some of those issues will come up on Dreamwidth as well, some of them won't, and some of them may only come up on Dreamwidth and not anywhere else.

As the need for policy becomes apparent, we'll tell you, tell you what those policies are, what problems they're trying to solve, and ask you if you can think of any technical changes we can make that will prevent the problem from happening. We always prefer to make a technical change that will prevent a problem from happening than try to design and enforce a policy around the problem.

How do you determine if something's illegal?

In most cases, we require a judgement rendered by a United States court or a Maryland State court saying that specific content is illegal. The exception is content that the United States Criminal Code specifically identifies as illegal and provides enough information for us to be able to definitively identify it, with no possibility of misinterpretation. Obviously, as the law changes, our policies will need to change as well.

It's very hard for us to give examples. In general, though, if we think it's not an open-and-shut case and that a court might say the content isn't illegal, we'll leave it alone and let the courts decide.

How do you define "defamatory"? How do you define "libelous"?

The Terms of Service prohibit defamatory and libelous content. These words have a specific legal meaning. In order for us to remove content on these grounds, we require a judgment from a United States court or a Maryland State court saying that the content meets these definitions.

In most cases, if someone posts negative things about someone, those things don't fit the legal definition of libelous or defamatory. We aren't equipped to make that judgment call. The best thing to do is to ignore it. (Or, make a post of your own to set the record straight.)

What are your copyright policies?

We are bound by the Digital Millennium Copyright Act (DMCA), signed into legislation in 1998. This law specifies how we must handle copyright complaints. For a description of our obligations and your rights involving copyright infringement, please see our DMCA Policy.

Overall Site Questions

Is Dreamwidth just another LiveJournal clone?

No. Dreamwidth is what is known as a "code fork". LiveJournal makes its code available under an open source license, which means that anyone can take the code, improve on it, and use it. We decided to take that code and make our own improvements to it: we've modernized the code, cleaned up a lot of the backend, added in a number of new features, fixed a lot of bugs that have always annoyed us, and otherwise done considerable work to take the whole project in an entirely different direction.

Is this a reaction to a specific decision LiveJournal made?


[staff profile] mark and I both worked for LJ for years, and both of us left at various points to pursue other opportunities, but both of us always loved LJ, both for what it was and what it could be. As early as 2004, we were having the kind of discussion that led to Dreamwidth's creation, and Dreamwidth is our attempt to capture all of the things that made LJ so awesome, while at the same time a). fixing a lot of the issues (both technical and social) we identified over the years and b). incorporating the lessons we've learned from working at LJ and watching other social media properties.

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.

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.

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 don't you have all the features LJ has, if you're based on the LJ code?

In some cases, it's because LiveJournal has chosen to make their implementation of the 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, their payment system, etc.

In some cases, it's because we feel that the feature, as implemented on LiveJournal, suffers from some usability problems, or because 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. Examples of this include ScrapBook (LiveJournal's image hosting system) and the to-do feature. We'll be providing alternate versions of these functions, which we'll design with you, using the process above.

In some cases, we've evaluated the features and decided that they don't fit what Dreamwidth wants to do, or don't fit our company's guiding principles. Examples of this include advertising, graphical previews, music auto-detection, and the ability for one user to flag another user's content for administrative review.

And finally, in some cases, it's because offering that feature would require external partnerships, or cost us a significant amount of money. 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 it won't be soon.

Will Dreamwidth be translated 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).

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.
zvi: self-portrait: short, fat, black dyke in bunny slippers (Default)

[personal profile] zvi 2009-04-10 05:32 am (UTC)(link)
This is gorgeous. However, putting everything under a single cut means I can't direct people to particular questions with internal page anchors. :(

But the new FAQ answers are really good.
pne: A picture of a plush toy, halfway between a duck and a platypus, with a green body and a yellow bill and feet. (Default)

[personal profile] pne 2009-04-10 10:37 am (UTC)(link)
However, putting everything under a single cut means I can't direct people to particular questions with internal page anchors. :(

Well, you can put in <h2><a name="anchorname">Section title</a></h2> without needing to put in another cut for each section.

Or even <h2 id="anchorname">Section title</h2>, but I'm not sure how widespread browser support for anchors as "id" attributes of arbitrary elements is, compared to "name" attributes of "a" elements.
snakeling: Statue of the Minoan Snake Goddess (Default)

[personal profile] snakeling 2009-04-11 06:55 pm (UTC)(link)
I think only IE5 don't support "id" as anchor, so I wouldn't worry about it.
ext_1770: @ newkidfan (fandom: spn)

[identity profile] 2009-04-10 12:08 pm (UTC)(link)
Thanks for the clarity of explanation here. :-)
ext_1770: @ newkidfan (fandom: sga)

[identity profile] 2009-04-10 12:22 pm (UTC)(link)
As it just so happens, I do have a question (but I'll stick to one so you don't regret the offer). When you go into open beta mode, will there be a way to treat someone to a paid account, without them already having an account over here? If they, say, had an open ID, could a paid account be gifted to that?
oxoniensis: close-up of a clock face (Default)

[personal profile] oxoniensis 2009-04-10 12:32 pm (UTC)(link)
Brilliant! I'm so pleased, and really glad I asked.

Is it April 30th yet?
sophie: A cartoon-like representation of a girl standing on a hill, with brown hair, blue eyes, a flowery top, and blue skirt. ☀ (Default)

[personal profile] sophie 2009-04-10 01:35 pm (UTC)(link)
The Wiki page would automatically generate a Table of Contents with links to all the questions at the top, which makes things really easy for people who want quick answers. Would be open to linking them all in a ToC here, too?
sophie: A cartoon-like representation of a girl standing on a hill, with brown hair, blue eyes, a flowery top, and blue skirt. ☀ (Default)

[personal profile] sophie 2009-04-10 01:49 pm (UTC)(link)
Sure - go ahead. :)

[identity profile] 2009-04-14 01:26 pm (UTC)(link)
Dreamwidth is not fandom-specific, but is fandom-friendly.

That is incredibly awesome.
paperdoll: (Default)

[personal profile] paperdoll 2009-04-19 03:32 pm (UTC)(link)
Wow, this is an awesome post! Thank you. Can't wait to see everything.
purpleparadox: (Chibiusa)

[personal profile] purpleparadox 2009-04-19 05:33 pm (UTC)(link)
Thank you for posting this. I'm really happy I made the choice to move over here. I originally joined LJ for the sense of community, and the opportunity to meet new people. Sadly, it's starting to turn into another Myspace or Facebook, and when my paid account there expires next week, my money will instead go here. (If only I had $200 laying around, I would love to get one of the seed accounts, simply to say "I've been here since the beginning", but I have no problem giving you guys money yearly, heheh)
ext_15707: (Default)

[identity profile] 2009-04-21 05:04 am (UTC)(link)
I found this very interesting and informative - I am so glad that you have decided against using previews.... when using a laptop with a small screen the images are so disruptive. I have them permanently turned off everywhere!

The LJ Scrapbook leaves a LOT to be desired, and I am currently using either Photobucket or my own web-space to host my journal's pictures.

Lastly, I just like to say that I like this idea: Dreamwidth is not fandom-specific, but is fandom-friendly.
ext_3468: Quark with a tribble on his head (Thinking)

[identity profile] 2009-05-01 06:35 am (UTC)(link)
Hrm... I just noticed you guys are a Maryland-based company, and that you ([staff profile] denise) are from Maryland. Does that mean you guys have a physical office in Maryland? If so, are you hiring, and if that's so, where can I send my resume?
ext_3468: Milo and Teddy from "AntiTrust" (Computers)

[identity profile] 2009-05-03 01:12 pm (UTC)(link)
That's cool. Thanks for the reply. (I also assume that you're renting server space elsewhere or something, because I highly doubt that either of you has room in your residences for racks of servers. :-D)
libitina: snake across an open book (Default)

[personal profile] libitina 2009-05-01 05:32 pm (UTC)(link)
*sigh* But I want the street cred of a seed account. I managed to have a friend help me catch the deadline and promise you a check... But I'd be willing to switch to a regular paid account, if it will really help.

If you had a random "donate here" button, I could have my street cred and give you $5 out of every paycheck.

Hmmm... that sounds vaguely grumpy. That is only because it is still pretty much morning for me. I am elated and gleeful about the awesomeness of Dreamwidth. I just watch in awe as every promise you made and dream we sighed out wistfully is being (surprisingly quickly) crafted and made work. It is just as happy-making as raunchy, kinky porn about characters I love to bits.
alicettlg: (Default)

[personal profile] alicettlg 2009-05-16 11:58 pm (UTC)(link)
oooooh! this is brilliant! I didn't get a seed account cause I don't have $200 lying around so I got a regular paid account but I'd be happy to donate more money on a fairly regular basis and this would let me help DW *and* someone else too!

You and Mark are WONDERFUL and it is so much fun watching this all work out so well!
alitalf: Skiing in the 3 Valleys, France, 2008 (pic#91180)


[personal profile] alitalf 2009-05-02 01:17 pm (UTC)(link)
I like your stated intentions. If that works out in practice as you and we would all hope, then Dreamwidth will, very likely, increasingly be seen as an attactive place, as momentum grows.
thewickedquill: turquoise hands (Default)

Wow :)

[personal profile] thewickedquill 2009-05-08 05:18 am (UTC)(link)
Just wanted to say that you guys totally sold me and I have big hopes now :) Your staff was also great at responding to an inquiry really quickly and with a very detailed and easily understood answer/s. I'm already impressed.

Am hoping to be able to invite some friends some time soon :) I think they might really enjoy the experience.

Have a great weekend!
flourite_roses: (Fai's smile)

[personal profile] flourite_roses 2010-06-25 12:52 pm (UTC)(link)
Hi, I'm a new user and someone has just recently given me a paid account for a month. Yay her! ♥ However, what happens after that one month? If I don't renew it, will the extra features just lapse? E.g. If i have 50 user pics, will all but the first 15 will be deleted?

I couldn't find any answers in the FAQ... T.T Then again, my searching stills suck.
cesy: Unofficial Dreamwidth volunteer (Dreamwidth volunteer)

[personal profile] cesy 2010-06-25 12:58 pm (UTC)(link)
The extra features will lapse, yes. The icons will still be there if you get a paid account again later, but you won't be able to use them.
flourite_roses: (Fai's smile)

[personal profile] flourite_roses 2010-06-25 01:22 pm (UTC)(link)
I see... This will be the same for the subscriptions and all? Thank you for the help! ^__^
cesy: "Cesy" - An old-fashioned quill and ink (Default)

[personal profile] cesy 2010-06-25 01:23 pm (UTC)(link)
I can't actually remember what happens to the subscriptions. Support would probably know.
alanj: (Default)

[personal profile] alanj 2011-08-07 06:58 am (UTC)(link)
FYI, all the pipermail links in this (otherwise excellent) post are currently broken.
brainwane: My smiling face, including a small gold bindi (Default)

[personal profile] brainwane 2017-04-10 11:09 pm (UTC)(link)
The "technical and business reasons" & "Followup explanation." messages are available via the Internet Archive.
(reply from suspended user)

Broken diversity statement link

[personal profile] ealex292 2016-07-24 06:45 pm (UTC)(link)
The Diversity Statement link in the post is broken:
> 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.

(It looks like the .bml needs to be removed.)