Those plans have now been finalized, and we will begin phasing them in this month.

Support Changes

We have broken up our human-provided support into three categories.

System Problem Reports

Any full member (sorry, not adjuncts) may submit a system problem report when they find something of ours malfunctioning that is affecting them. This might mean a site is down, or a MySQL process is crashed, or the member UI is giving them an error whenever they try to frotz the burin.

We will investigate the report as soon as we can (even outside our support hours if possible) and provide a brief response including a predefined finding and, at our option, a comment of up to one line. (This makes system problem reports not suitable for asking for other types of help.)

Assistance Requests

When a member needs us to do something that they are not able to do for themselves, either due to security limitations or a feature gap in our member interface, they can open an assistance request. These are no-cost support requests on specific topics that offer prepared guidance as far as what they encompass and what information you need to provide (if any). Examples include adding ssh keys, transferring stuff to someone else, or (whimper) canceling your membership.

We will take care of assistance requests during our regular support hours.

Secure Support Requests

These are the “catchall” for issues not covered by the other two avenues and not suitable for our member forums, and questions not covered by our FAQ or member wiki. This includes issues where you need us to investigate something on your behalf or provide basic advice about how our system works that isn’t covered elsewhere and isn’t suitable for our forum.

The following topics are specifically excluded from secure support issues because they are simply beyond the scope of the support we have the resources to provide:

• training of any sort
• web page design, uploading or consulting
• help using or configuring third-party software
• programming or debugging assistance
• re-explanation of things documented elsewhere on our site, other than very specific questions that have straightforward answers

Effective August 15th, 2009, you will need to have support points to open secure support issues. Support points will be available 10 for $5.00. They never expire, and can be “sold back” if you close your membership.

Each response we send you on a particular issue will carry a point cost from zero to ten points based on the time we spend and the complexity of the request, as determined by us. That cost will be deducted from your support points balance. If your support request requires multiple responses (e.g. multiple questions or back-and-forth exchanges), each response from us may carry a separate point cost. If you run out of support points, open tickets will be suspended until you add more, and new ones will not be able to be created.

The option to mark a secure support issue of “high” priority will be available for an extra up-front point cost: two support points during support hours and five support points outside support hours. While we frequently respond to “high” priority requests submitted outside business hours, we cannot guarantee any specific response time, only that we will look at them as soon as we can and, if necessary, move them to the front of the line when support opens.

Once the system has been operating for a few months, we will try to gather and make available some statistics about how much support requests cost to help members plan accordingly.

Service Pricing Changes

We are implementing five pricing changes:

The exact DNS charge will vary based on whether or not the domain is registered and/or hosted with us. See our public site for complete details; the detail page for each service is linked in the table above.

These changes will go into effect on or after September 1st, 2009 for affected services created after 2PM Eastern time today.

Temporary Grandfathering

Every site, domain, and MySQL process that existed at 2PM Eastern today has been exempted from these pricing changes until at least October 1st, 2009.

Beyond that, we’ve extended the grandfather period for each item by an amount based on when it was created. You will be able to see each “Exempt Until” date in the member interface later today.

The Road Ahead

We will be making many updates to the content of our public and member sites and our FAQ today to reflect these changes, so please bear with us while we go through that process. Once this post is up and our public site is updated, we will be doing a (rare) email notification to all of our members with funded accounts to inform them about the changes.

After that, we still have implementation and testing to do on these changes, so that’ll keep us busy for awhile.

Once that’s done, we do still plan to revise our single storage pricing fee into separate fees for storage and CPU/RAM usage to better apportion hardware costs to the sites that incur them (thereby sharply reducing the cost of hosting sites with large static content). We plan to do that in conjunction with the release of a couple of new features, hopefully within a few months.

Thank you!

Thanks for your patience with us while we worked out the changes that we feel will best befit our goal of continuing to promote legitimate freedom of expression by creating the best and most flexible hosting possible and offering it as affordably as possible to as many people as possible.

I’d like to (again) offer special thanks to the hundreds of people who offered comments, feedback, and suggestions in response to this proposal. You need only look at how different and how much better these changes are than our initial ideas to see what an impact you’ve had.

And, last but not least, thanks for being a member of NearlyFreeSpeech.NET!

Update

I thought I’d update this post to add some of the questions that seem to be getting asked over and over. Quite a bit of this was covered in the pricing discussion in our forums, but we recognize that not everybody wants to read 30+ pages of comments and feedback.

Q. Doesn’t this new pricing make your service very expensive?

No it does not. We ran the numbers, and over 50% of our current paid member accounts will pay less than $18.50 per year with our new pricing based on their current usage. That’s per year, not per month, and it includes domain registration fees, as well as MySQL, DNS, sites, bandwidth, email forwarding, and storage for everything they currently have set up with us.

We are 100% comfortable looking at those numbers and concluding from them that if 50% of our members can host, on average, multiple web sites including their supporting services and domain registration for about $1.50 a month, NearlyFreeSpeech.NET remains very affordable and a great value for small sites and light usage.

For people who work with our system to optimize their usage as much as they can, it’ll be even more affordable.

Q. Is it fair to charge a flat $0.01/day fee to tiny sites that used to pay a few cents per year?

Yes it is.

There are various ways to approach understanding this, but here’s the simplest way to explain it. “Fair” is defined by what happens if everybody does something. So, we ask this question: If every site were a small PHP/CGI-using site that got almost no traffic and got by on pennies per year, would we be able to stay in business from the revenue they generate? Quite simply, the answer is no.

That answer, all by itself, means that tiny sites are currently not paying their fair share. It means a baseline cost exists on a per-site basis regardless of the size of the site. (The details are quite a bit more complex and we’ll have to send you to the discussion thread for that.)

The followup question is: what is that baseline cost that needs to apply per-site to every single site, in order to make sure that we can continue in business if everybody ran tiny sites like that. It turns out that it’s $0.01/day. Every scheme that attempts to shift some or all of that expense to larger sites represents subsidizing small sites by charging large ones more. That is unfair.

Large sites already pay too much, as evidenced by the commenter below who remarked that he recently moved his site because it finally “got big” and implied that doing so was a foregone conclusion. Sadly, he’s not wrong. So, charging them more in order to preserve the “small site subsidy” is not an option.

We do understand that this is hard for many people to understand. We have spent seven years telling them that only machine costs matter, that it doesn’t cost anything to have people around to run the equipment for them 24×7, which is completely wrong, and we haven’t done anything to discourage “site sprawl” where people create sites at the drop of the hat because “they don’t cost anything.” These changes represent a huge shift, and we understand that some people will take time to adjust, and a few may not be willing or able to do so.

Q. Is it fair that all dynamic sites pay the same fee regardless of how processor intensive they are?

As far as the baseline fee which, as outlined above, we believe is fair for every site even if it does nothing at all, yes.

Beyond that, no. However, that isn’t a function of the per-site fee. Rather, the unfairness arises from tying sites’ resource-based billing solely to the amount of disk space used, rather than to some combination of disk space, CPU, and RAM. As outlined in the original blog post, this one, and many times in the discussion forums, we recognize and acknowledge the fundamental unfairness of that.

It is something we desperately need to move to correct. We will do so soon, but not now. The reasons for that have been covered elsewhere, so we will summarize them very simply by saying: we need this change to get to that change.

Q. If all this is true, how did you get this far?

At our current size, the founder of our company (that’s me) has been doing the work of 2-3 very expensive full time professionals without getting compensated for it. The effect of this has been to drastically hold down the cost of providing our service, that, even more than large sites, is where the existing subsidy of tiny sites comes from.

This introduces two problems. First, it doesn’t scale. As we continue to grow, the quantity of work increases but the quantity of founder does not. Second, it makes the operation of the company unacceptably dependent on one person; if anything bad ever happens to that person, the company and every member will be screwed because the money won’t be there to hire.

We’ve reached a point where we were faced with two choices: continue down that road and watch the quality of our service spiral into oblivion or take concrete steps to ensure that we have the people and resources to provide a strong, stable, sustainable organization that can provide the quality level we consider acceptable without being critically dependent on a single person who must never get sick, take a day off, or be killed by a falling bus. We chose the latter.

Q. How do I mark my site(s) as static so I won’t be charged the dynamic site fee?

Please see this entry in our FAQ.

We will provide additional reference information about static sites in the near future to help you get the most out of them.

Q. How do I minimize the impact of these changes on me?

There are several things you can do:

First and foremost, remove services you set up but aren’t using. This one is huge. So far, of the people who have written private feedback or cancelled, more people have commented that this change prompted them to clean up stuff they forgot about than have said they were put off by the pricing changes. One person said that after cleaning up stuff he wasn’t using, he’ll be paying less with the changes than he was before.

Second, make sure your domains are lined up with our registration, DNS, and hosting wherever possible. The “trifecta” discount for DNS is about 89%. If you’re using our service to provide DNS for random domains that are registered and hosted elsewhere, you’ll want to take a hard look at alternatives.

Third, switch to our static site type for any sites you have that don’t need scripting (PHP & CGI support). This includes the majority of sites built with web design tools.

Fourth, if you have a bunch of dynamic sites or multiple MySQL processes, explore what opportunities you may have to consolidate them. We will do a whole blog post sometime in the next few weeks discussing various options in this area. We also plan to offer features that will greatly enhance the power and flexibility of each site, a side effect of which will be making consolidation even easier, but of course we can only do that if doing so is financially viable (meaning we need these changes to be already in place).

Fifth, if you are using are email forwarding service, make sure you’re not doing so from inertia. It is a giant pain for us to maintain and eats a lot of resources, and it is priced accordingly. We consider it undoubtedly the worst value proposition of any service we offer as far as what you get for what you pay for. If you need it, we have it, but there are a lot of really good alternatives that are worth a look.

Q. Do you plan to give bulk discounts to people with tons of tiny sites?

We do not; this is behavior that incurs real costs for us. Such a plan would simply unfairly shift those costs onto people who use less services.

What we will do in the future is provide additional ways to do more with fewer sites, as outlined above.

Q. What are the moderation criteria for comments?

We have been able to approve almost all of the comments people have made on this posting, with a handful of exceptions.

Comments will not be approved if they:

• Ask questions that are off-topic or too tangential. (Please post them in our forums.)
• Repeat questions that have already been asked and answered.
• Threaten or insult us or other commenters
• Factually misrepresent the changes or their effects (such as claiming that we’ve instituted a fee to report system problems).

Most of that should be common sense, but we wanted to be very clear about it anyway.

One of the things we are running into with our pricing model is that the resource-based pricing we currently use doesn’t take everything into account, and doesn’t always do so accurately. That’s something we need to address.

For example, the price for storage is problematic, because it’s a machine resource we can measure, whereas CPU and RAM are (currently) not. It’s not that this charge is too high, as people sometimes like to use apples-to-oranges comparisons to claim, it’s that it’s improperly apportioned. People with large, static websites pay too much and people with small, CPU-intensive websites pay too little. This is a measurement problem more than anything, and it’s one we’ll address over time as we roll out the “arbitrary server process” technology that’s been under development for so long.

However, although that’s a good example, we have a more immediate problem that is not only keeping us from solving it but also gaining significance as we continue to grow. In addition to CPU and RAM, there is another hugely expensive resource that we are not recovering costs for: people. Since we are small organization that is very efficient and low-overhead, this comes in two forms: member support, which scales with the number of members we have, and system administration, which scales with the volume of services we provide.

Our service was designed with no “human” cost component because, at that time, I was the only person involved and I didn’t get paid. Support was intended to be limited to helping members when the system was broken, or with things that our system prevents them from doing themselves, and the service was priced accordingly. However, that was a long time ago. Now we have reached a point where over 50% (and approaching 75%) of our support requests do not fit the original design: they are from people who want to pay our prices but still get unlimited technical support and assistance. And we have to pay people to handle them. On average, each support request costs us $3.30, so that’s just not sustainable.

On the system administration front, our members (rightfully) expect us to provide a server environment that is carefully monitored, ruthlessly secured, relentlessly kept up to date, continually enhanced with new features, and where even the smallest performance and downtime problems are detected and responded to immediately by experts 365×24. But, despite that expectation, our members do not pay us to do so because here again, the prices were designed back in 2002 when I was the only person involved.

Therefore, as with support, the now-immense costs associated with system administration go unrecovered. Unlike support, the consequence is that we’re seriously understaffed in this area, and every NearlyFreeSpeech.NET member has in some way or another felt the repercussions: downtime, suboptimal performance, and endlessly delayed new features. As we continue to grow and the workload increases, the rate at which our list of unfinished to-dos expands simply accelerates. That, too, is unsustainable.

In order to properly staff NearlyFreeSpeech.NET to the level where we can provide the quality of service and support that our members expect, and get research and development of the new features everybody wants off of the 0-2-hours-a-week back burner, we need to start recovering an average of $2.50 more per member per month.

We’re going to do that, and we’re going to do it very, very soon. The only question is how we go about it. We want to be very careful not to repeat our storage pricing mistake: we want to apportion costs among our members as fairly and accurately as possible in proportion to their resource usage. That means imposing at least two new charge structures, one for support and one for system administration.

That’s because a whole lot of our members never use support at all. We strongly feel that they should not have to subsidize the other extreme: people who submit “high” priority support requests in the middle of the night demanding that we answer questions they could have just as easily found in our FAQ. So, what we’re leaning toward is a three-tier membership model:

- A “basic” membership, which carries no monthly charge but has no included support eligibility. Support requests can be submitted at normal or low priority for a $3.30 charge.

- A “standard” membership, which has a $1.00/month charge and includes one support request at normal or low priority per quarter. Additional support requests can be submitted at any priority for a $3.00 charge.

- A “premium” membership, which has a $2.50/month charge and includes one support request per month. Additional support requests can be submitted at any priority for a $2.50 charge.

In addition to support requests, our forum will remain free-to-post and we plan to implement a system to compensate the dedicated forum participants who we recognize are volunteering their time to make our service better by helping out their fellow members.

On the other hand, every single member needs us to have sufficient system administration resources to keep things running. The best plan we’ve come up with so far is to consider the “objects” that form a person’s services. As we define it, each of these is one object:

- one web site
- DNS for a single domain
- one MySQL process
- email forwarding for one domain

We’re considering applying a one-cent-per-day-per-object system administration surcharge to each account. The average member has 5 objects, so that would be an increase of about $1.50/month to them. That seems pretty reasonable in exchange for ensuring that we have the staff needed to keep an important website secure and available. But for people who need to squeeze out the maximum hosting-per-penny, it’ll still be possible to host a site in our domain (or with 3rd party DNS) that uses SQLite and limit the system administration surcharge to one penny per day.

Neither of these plans are finalized, but we’re moving rapidly in that direction. I’m posting this now for two reasons. First, because we’re committed to transparency in a way that nobody else can touch, and that demands we do so. Second, because we want to get as much constructive, helpful feedback as we can about how we can fairly distribute these costs over our member base.

Threats to cancel if we do (or don’t do) XYZ will be ignored. Simple economics dictates that any increase in prices will decrease demand; we already know that whatever we do will cause some people to stop using our service.

Some people may genuinely not be able to afford any increase; to those who are not able to rearrange their usage under whatever plan we come up with to reach a cost structure they can afford, we apologize that we are likewise not able to afford continuing to subsidize them. But we expect the loudest complaints to come from a small subset of members who voraciously consume our time and feel entitled to do so for free. This latter group is essentially strangling our business, so although converting such people to have sustainable, success-aligned goals (where they and we both gain) is our first choice, eliminating them as members if they are unwilling to cooperate is an inferior but acceptable alternative.

Likewise, exhortations not to change anything “because its fine the way it is” will also go unheeded, because it is not fine the way it is. We are not happy with the system quality we are able to deliver at current levels, so our options are to raise prices for the people incurring the costs or start zeroing in on members that we lose money on and terminating them, just like a lot of web hosts already do. And if that’s not enough to convince you, head over the the feature voting page and take a look at how far behind we are.

NearlyFreeSpeech.NET is not on the precipice of doom or anything; we balance our checkbook at the end of every month without going into the red, just like we’ve always done, and there is usually money left over for pizza. That, by us, is success. But we can see that if we don’t take corrective action, the quality of our service will inch downward until it reaches a threshold of “it’s cheap, but it sucks” that we’re not willing to approach, let alone cross. Knowing that we need to do something, the responsible approach is to do it as soon and as well as we can. So here we are.

Currently, we have to draw money out of our service and hardware budget to pay our human costs. With these changes, human costs will be paid for by the new charges instead. If things turn out the way we expect, we plan to use part of what that frees up from existing revenues to accelerate our service buildout (software and hardware) and we plan to return part in the form of reduced costs on some of our services. But first, we have to see things turn out the way we expect. So the changes outlined above aren’t intended to be the final word on the subject: things will get a bit more expensive, and then they should get a bit cheaper again.

As I said at the beginning, NearlyFreeSpeech.NET is not designed to turn a profit, its fee structure is designed to recover the costs of providing the service in the most fair and straightforward manner. That will remain true, even as we make the necessary adjustment to include the human cost in our fee structure. “As cheap as possible, but no cheaper.”

Thanks for your time, for being a member of NearlyFreeSpeech.NET, and, I hope, for your valuable feedback as we contemplate the best way to implement this change together.

We want the response to this to be a discussion, and blog comments don’t allow the easy quoting and attribution needed to facilitate that — I cringe every time I have to edit someone’s comment to add a response — so we are closing comments on the blog post and directing follow-ups to this thread in our discussion forum. That discussion is going to move fast, decisions will be made quickly, and changes will follow sooner rather than later. So if you want to be heard, now is the time.

Update

Based on the feedback we have received, we have made several significant changes to the plan. A summary is presented here for people who don’t want to read the whole discussion thread. This is getting close to being finalized, but is not yet set in stone, so please feel free to provide additional feedback. We would like to announce the final plan to all members via email sometime around the weekend, if possible.

Pricing Changes

Support Pricing

With this change, most support will be provided through the use of “support points,” which can be purchased in increments of 10 for $5. Unused support points do not expire and can be “sold back” when a membership is closed.

Submitting a support request will require you to have at least 1 support point. Each response you receive will be assigned a cost from 0 to 10 support points based on the time and complexity of the request, as determined by us, which will be deducted from your support points balance. If your support request requires multiple responses (e.g. back-and-forth exchanges), each response from us may carry a separate point cost. If you run out of support points, open tickets will be suspended until you add more, and new ones will not be able to be created.

Certain requests will default to zero points until they are implemented as features in the UI. These include:

- SSH key management
- Your first IP access control modification in a given week
- Chowning files from the “web” user to your site UID.
- asset transfers between members/accounts
- Canceling membership

We plan to implement “stub” features in the UI to open tickets for these types of requests without the need to obtain support points. If additional help is needed with such a request (such as troubleshooting a non-working ssh key), we may assign point costs as appropriate to cover our involvement.

The option to mark a request as “high” priority will be available. This will require 2 support points during our business day and 5 points at other times. This is a way to bump your request to the front of the line. While we frequently respond to “high” priority requests submitted outside business hours, we cannot guarantee any specific response time, only that they will be handled no later than first the following day.

To prevent people from having to pay a fee to report problems, we will implement a “problem report” option that will allow opening a ticket even if zero support points are available. To minimize misuse, our responses to such will be minimal, possibly stock answers, unless we need more information. In cases where misuse is a recurring problem, we reserve the right to block individual members from submitting problem reports. We intend to treat problem reports as high priority requests unless the rate of false positives proves problematic for us.

The estimated effective date for new support charges is August 1st – 15th.

Hosting Pricing Changes

Our new table of hosting service fees will be as follows:

- Bandwidth – $1/GB “or less” (existing sliding scale)
- Storage – $0.01/megabyte-month*
- Web Sites – $0.01/day/site
- First MySQL process – $0.02/day
- Additional MySQL process – $0.03/day
- InnoDB MySQL – $0.01/day/process
- DNS service – $0.01/day/zone
- RespectMyPrivacy – $0.01/day/domain
- Email Forwarding – $0.03/day/domain
- Domain Registration – $8.59/domain/year

Two discounts will be available when this change takes effect.

With respect to DNS, if the domain is registered with us or if www.(domain) is pointed at a site hosted here, then the DNS object pricing will be cut by a factor of 3 ($0.01/3-days). If both apply, then the DNS object pricing will be cut by a factor of 9 ($0.01/9-days). (This is a bit of a conscious effort on our part to reward people who are using our DNS and domain registration the way we intend — with our hosting.)

With respect to the per-site charge, sites using the currently-experimental “static content” site type will be exempt from the fee, as we will be handling those sites in a way that requires significantly less overall maintenance on our part.

*It is our intention to reduce storage pricing and add a “workload” billing factor to account for CPU/RAM resources used. It is our intention that this change will be revenue-neutral with the current storage charge but will more accurately apportion the machine costs of providing the service between individual sites. Specifics and timeframe are TBD.

The estimated effective date for new hosting charges is September 1st – October 1st.

What if they didn’t?

We have long offered a plan called “bandwidth buckets” designed to let people who knew in advance that they would be using more bandwidth. However, this program was never terribly popular, partly because it’s pretty complicated and partly because it requires a lot of micromanagement and a fair degree of prescience to make the most of it. We’ve killed it. (Naturally we’ll honor all previously-purchased bandwidth buckets.)

As of February 1st (midnight UTC), we’ve begun tracking the total bandwidth used by all the sites in each personal bandwidth account. The 1GB/$1 pricing will remain unchanged. The change comes on the second gigabyte. The short version for nerds like me: from now on, the number of gigabytes you can buy with $1 increases from 1 GB to 5GB proportional to the base-10 log of the number of gigabytes your account has used. If you think logs are for sawing, here’s a breakdown using nice round numbers:

1 GB = 1GB / $1
10 GB = 2GB / $1 ($0.50 / GB)
100 GB = 3GB / $1 ($0.33 / GB)
1000 GB = 4GB / $1 ($0.25 / GB)
10000 GB = 5GB / $1 ($0.20 / GB)

But here’s the cool part: those numbers are examples, not tiers. As soon as you’ve used that first gigabyte of bandwidth, your prices start coming down. As of now, the number of bytes you get for a penny is displayed on your account page. After that first gigabyte goes by, this number starts to climb. And it climbs fast. Take a look at this breakdown, which shows the first few gigs:

1GB = 1GB / $1
2GB = 1.30GB / $1
3GB = 1.47GB / $1
4GB = 1.60GB / $1
5GB = 1.70GB / $1

That’s right, you’re now getting about 30% more for your bandwidth dollar after your second 2GB, and 70% more after just 5GB. This is an automatic discount; you don’t have to do anything to get it. But you don’t even have to get to 2GB. If you’re on your account page and you’ve accrued more than a gig of transfers, you can actually hit reload a minute later and see your bytes-per-penny increase. You can watch your hosting getting cheaper in real time. I’m actually kind of obsessed with watching mine, probably for the same just-a-few-more-points reason I’ll never be allowed to play World of Warcraft.

These discounts aren’t monthly or anything; the more you transfer, the cheaper your service gets, no matter how long it takes. It’s also permanent for the life of your bandwidth account and applies immediately to new sites you create on the same account. We’ll be posting information about this on our public site over the next couple of days.

This is absolutely not designed to compete with the bajillion-gigs-for-$9.95-a-month* plans out there. Those plans are based on overselling, not actual cost of services. We’ll never go down that road. Instead, we’ve been waiting a long time to get the purchasing power and volume discounts needed to make hosting even more affordable for our members, and it’s very exciting that after six years, we’re finally here.

So your mission, should you choose to accept it, is to get out there and use more bandwidth. Hey, you can afford it!

*Bajillion-gigs-for-$9.95-a-month offer not available for websites containing graphic files, videos, scripts, large downloads, small downloads, text, HTML documents, or websites that anyone might want to visit.

UPDATE: We’ve added a Bandwidth Calculator to our public site to help you figure out how much certain bandwidth costs. Turns out the formula is given as:

(This entry was updated on January 10, 2009 to use a more accurate formula from our Wikipedia entry.)

On October 12th, our pricing for all the top-level domains we support will increase from $7.50/year to $7.99/year for all domain registrations, renewals, and transfers. All other pricing, including RespectMyPrivacy.COM, will remain the same.

It is possible to renew domains for multiple years (up to 10 total), so if you know you’re keeping your domain and you want to get those years at the best possible price, we urge you to renew before October 12th. You won’t lose any current registration on your domain; renewals will add right on to the end of the current expiration date.

The sky is not falling, and the world will definitely not end if you don’t renew your domains before the price increase, but I know a lot of our members like to optimize their costs down to the last penny of savings.

• About 25% of our members have ever interacted with our support system.
• About 14% of our members have opened more than one support issue.
• Over 50% of our support issues come from under 5% of our members.
• Providing support is our single largest recurring monthly cost line item. That means it costs us more than we pay for bandwidth.
• The cost of providing support is growing at a faster rate than any other cost.

In other words, 75-95% of our members are paying to subsidize the support requirements of a small minority. Although that raises some serious issues about fairness, it isn’t really unusual; most hosting companies operate exactly that way: they build a certain amount into their monthly fee to each user to subsidize the cost of providing support to the small portion of their userbase that requires it.

However, as you know, we don’t have a monthly fee. That means the support subsidy has to come from somewhere else. At NearlyFreeSpeech.NET, it’s currently coming out of the R&D budget. So while our entire member base may not be paying a fee for support they may or may not use, you most definitely are paying for it in terms of reduced functionality and delays in rolling out the new features and services you want.

This is particularly frustrating since we’ve always presented ourselves as a no-frills, do-it-yourself host with limited support that does a lot of R&D that you simply don’t get anywhere else.

Obviously, we need to make a change to get back to our core values.

Effective immediately, we are changing our standard support hours and implementing an optional “Extended Support” plan.

Our new support hours for standard issues are:

• Monday through Friday, 10am – 6pm
• Saturday and Sunday, 12pm – 4pm, Pacific Time

With Extended Support, hours for standard issues are:

• Monday – Friday, 8am – 8pm
• Saturday – Sunday: 11am – 5pm, Pacific Time

Standard issues are those typical questions we receive that don’t pertain to downtime or other serious problems with the service. We’ll be continuing to do our best to address emergency issues as quickly as possible, regardless of our stated hours.

Wider hours are not the only benefit to Extended Support:

• Members with extended support will have their standard issues prioritized over other standard issues.
• To ensure timely and fair support to all members, we may occasionally delay response to standard issues raised by those members who submit an above-average number of standard issues. Members with extended support who submit an above-average number of standard issues will encounter shorter delays than they otherwise might.

The cost for Extended Support is $1.00 per month. Unlike most of our services, it’s purchased one month at a time and billed in advance. Once activated, it can be set not to renew at any time without affecting any time remaining in the current billing period. Since for most moderate users, the bulk of their support issues arise in the first month while they are getting set up, they can add Extended Support if they wish, and then remove it once things are humming along smoothly.

The revenues we generate from Extended Support will go directly to pay the people who provide support. Once we have enough Extended Support members to cover the costs of the current extended hours, we’ll start widening the extended hours. Should we reach 24×7 extended coverage, we can evaluate widening the scope of the support we provide.

I want to emphasize that Extended Support is optional. If you don’t use our support, this doesn’t affect you at all, and no one is required to sign up for it. If you value our support, and you want to show it, this is an excellent way to do so.

This is definitely a sort of social experiment, to see if the people who interact with our support system find enough value in that system to cover the associated costs. If it is successful, we will be able to extend and improve that system in a way that would otherwise be impossible. If not, we will have to evaluate our support offerings and look for ways to constrain it to a manageable cost.

However, as time goes on, MySQL is becoming more of an issue. Not only is each successive release more demanding in terms of CPU and memory, but as time goes by, the things our members are doing with MySQL become more intensive as well.

One good example of this is InnoDB tables. When we started, the current version of MySQL was 3.x and there was no such thing as InnoDB. Even when it became part of the distribution in 4.x, it wasn’t used very often (although its mere presence causes MySQL RAM usage to skyrocket). Now, some applications, like MediaWiki for example, will use InnoDB tables by default. Similarly, we would like to start making MySQL 5 available, but it promises to ratchet up the resource requirements once again.

Originally, we planned to extend the storage-based model to MySQL, but what we’ve found is that not only is this not a great model for MySQL, but the accounting mechanism would waste a lot of disk I/O, which would slow down everyone’s databases. By “not a great model” I mean that our MySQL servers don’t share a storage pool the way our web cluster does; each MySQL server has an independent local RAID to maximize performance. Due to the size of disks these days, these servers always run out of I/O capacity or CPU or memory well before they run out of disk space. MySQL is becoming progressively more expensive to maintain, and we need to find a way to recover the cost of its servers that is based on the resources that actually do run out.

Therefore, we are implementing the following pricing scheme for MySQL, effective January 1st, 2007:

• Your first MySQL process will be charged at a base rate of $0.01 per day.
• Your second (and successive) MySQL processes (if any) will be charged at a base rate of $0.02 per day.*
• If a MySQL process has InnoDB tables enabled, it will be charged an additional $0.01 per day.
• If a MySQL process is in the top 10% of MySQL CPU users for a given day, we will apply a $0.01 surcharge for that day.**

This means that roughly 90% of our members will see a MySQL fee of $0.01 per day (about $3.65 a year over existing prices). In the worst-case scenario, a member’s second MySQL process that has InnoDB enabled and is in the top 10% every single day would top out at $0.04 per day (about $14.60 per year), which is not unreasonable for a MySQL process that’s obviously seeing consistent high-volume usage.

*Once these changes are implemented, we will remove the restriction of one MySQL process per member.

**It is unlikely we will have the mechanism to charge for this in place by 1/1/2007, but if not, it may go into effect at any time after that.

If this is the only post you see in a category, it just means the category hasn’t been assigned any real posts yet.