This isn’t intended to be such a post.

This is a post to acknowledge that our service has a couple of serious issues that require more urgent attention.

1. The cost and threat of DDOS attacks is escalating so quickly that unless we act, they will drive us out of business.
2. It’s time for us to move toward ICANN accreditation.

Addressing these concerns will require some major shifts in our pricing model. To be completely honest and upfront, these changes will primarily affect those sites and members that are currently paying the least. After the changes, the prices at the low end will still be low, but not as low, and in some cases, lower-cost sites may have a different set of options than they have in the past.

Summary of changes

Here’s a short summary of the changes we are making:

• We are eliminating the current static/dynamic site distinction in favor of three tiers (plan selection available on November 1st, existing sites with no plan billed as Non-Production as of November 1st, and as Production sites as of December 1st):
  • Non-production site ($0.01/day) – Static and dynamic functionality, limited realm selection, limited # per membership, might be automatically opted in to some betas, not for production usage or revenue-generating sites;
  • Production site ($0.05/day) – The “standard” option. Full set of realms, unlimited quantity, no automatic beta opt-ins, usable for production or revenue-generating sites; and
  • Critical site ($0.50/day) – An option unlike anything we’ve (publicly) offered before with 24×7 custom monitoring.
• Bandwidth charges will largely be eliminated (not officially, but in practice, no one will pay them). (Effective November 1st for new sites, on or before December 1st for existing sites.)
• Resource (CPU/RAM) charges will decrease over 60%, from 17.22 RAUS/penny to 44.64 RAUS/penny.
  (Effective November 1st for all sites that use resource billing.)
• Domain registrations will increase by $1.00/year. (Effective October 1st.)
• We will be adding a significant fee to certain violations of our Terms & Conditions of Service that are extremely rare but cause significant hassle for us. (Effective immediately, with a limited amnesty period until December 1st.)

Below, we’ll discuss why we need these changes and then go through them in detail.

About DDOS attacks & bandwidth

Defending against DDOS attacks is very difficult and very expensive. The first key step to fight them off is being able to absorb the inbound traffic they generate. That takes massive amounts of bandwidth. And although already massive, the amount needed is constantly increasing. Right now, we have enough bandwidth to cope with about 70% of the attacks we encounter. That 70%, of course, starts from the bottom. And the success rate is falling. Larger attacks can knock our entire service offline, at least for a little while.

Unfortunately, this is an area where “pay for what you use” simply no longer works. We charge for bandwidth based on outbound traffic from member sites. But we pay for vastly more bandwidth than that to deal with attacks, and we need more still.

Worse, the equipment needed to mitigate DDOS attacks at wire speeds of 40Gbps and 100Gbps is pick-your-jaw-up expensive compared to 10Gbps gear (or, really, anything else we currently use), and it needs both costly maintenance agreements to stay up to date with evolving attack techniques and well-paid professionals to keep it all working.

So what we currently charge is not covering what we currently pay, much less the additional costs it would take to get the success rate up to 85-95% and keep it there as attacks increase in frequency and scale. That’s got to change. We need to increase our revenue, not just enough to cover our current costs, but to cover the additional costs of the bandwidth, equipment, and people necessary to make sure our service is secure, protected, and reliable, now and in the future. That entails charging everyone more.

Most people’s first reaction to that is, “Well, I’m not getting attacked, why should I have to pay more?” Here’s why: most of the sites affected by any given DDOS attack are not the site being targeted. That’s getting worse. We’re seeing more and more attacks on infrastructure, rather than hosting IPs. In such attacks, collateral damage is the whole point. Those typically affect everyone, and are often much harder to deal with. When your site is negatively affected by a DDOS attack on someone else, these are the resources we need to have even a chance of doing something about it.

Even if an attack targets a specific site we host, attacks are frequently non-specific enough that we never figure out who it is. But in those cases where a specific site is being targeted and we know which site it is, does it matter? Sometimes it’s easy to argue that the site operator must have done something to provoke an attack. And sometimes that’s even true. But it’s frequently not. In the longest and most debilitating attack we’ve ever experienced where we identified the target, that target was a small site about a video game. Did that site “deserve it?” How about the website for the orphanage using the same IP address? Should we just wash our hands of it and tell that person, “Sorry, you have to go elsewhere, video games are way too controversial for us to handle?”

Even if we do know the target of the attack, and it’s not just “us,” it’s not like we can send that member a bill. I mean, we could, but nobody is going to pay a surprise $10,000 bill from a service that claims that you’ll never be on the hook for more than the amount of money you decide in advance to put in.

“Who should have to pay for protection from DDOS attacks?” is a trick question. No one should. Period. Because DDOS attacks shouldn’t happen. They definitely shouldn’t be several orders of magnitude easier and cheaper to launch than they are to defend against. But “should” and “is” are miles apart, and we have to take the world as it is, not as it should be. So who does have to pay for protection from DDOS attacks? Everyone.

Protection isn’t optional. There’s no point in offering our service if the minute anyone calls our bluff we have to fold. We’ll never be able to provide every site protection against every attack. There are other — much more expensive — services like Cloudflare’s $200/month “Business” plan that can help sites worried about the last few % of attacks we can’t hope to mitigate. But we can do a lot better than this, and we must do better than this. Free speech, it turns out, is heinously expensive, and the cost is rising rapidly.

Hence, we’re changing our pricing to reflect that all sites, regardless of size or activity, must contribute toward the collective cost of protection from attacks. That wasn’t an easy decision, but we believe it’s the only workable option in the current online climate.

New site types

Non-Production Sites ($0.01/day)

We know that some people who host with us really do need the absolute lowest possible price, and this is it. This is a plan designed to minimize the price by reducing access to some features that are expensive for us, and giving us some flexibility with respect to how we host these sites. As such, this offering represents a subsidy; it’s below our costs. That has three main consequences:

• Non-Production Sites may not be used for production services, or for sites that generate any kind of revenue. If you’re making money on your site, we’re not willing to lose money to host it. Personal sites are OK. Beta sites are OK. Development sites are OK. Resume and portfolio sites are OK.
• Non-Production Sites must constitute no more than half of the sites on your membership, rounded up. So if you’ve got one site, it can be non-production. If you’ve got more, you’ll have to maintain a mix. If your ratio falls out of balance (e.g. by deleting Production sites), we’ll apply an adjustment charge.
• Non-Production Sites will help us improve our service. When we need sites to help test new features in the future, those sites will be automatically drawn as needed from the pool of Non-Production sites. They will also be limited to upcoming stable, beta and experimental realms to help us make sure third-party software updates are production-ready. (Realms are the huge collections of third-party software we provide preinstalled for all sites. Stable realms are rotated quarterly, and beta and experimental realms receive continuous rolling updates.)

If any of those limitations are undesirable for any reason, then a Production Site will be the more appropriate option.

We’ve found it’s faster, easier, and cheaper for us to develop and test new functionality when we have a robust base of real-world sites to test against. Our free bandwidth beta is a good example of such a test. That’s valuable to us, and that’s why we’re willing to offer this service at this price. We’ll make every effort to limit testing to sites that are compatible with whatever is being tested, and if the test breaks a site we’ll either opt it out if we detect that, or provide you a way to do so. And we’ll spread tests around to the best of our ability; it’s not our intent to draft every site into every test.

Whether or not a non-production site is participating in a test, we’ll still take feedback and problem reports about them, and we’ll still do everything we’re currently doing to keep them up and running.

Since this plan represents a subsidy, we have a certain amount of money in mind that we’re willing to “pay” our members for giving us the extra flexibility this plan provides. We’ll periodically evaluate the total number of non-production sites and may adjust the cost of this option if adoption rates are materially higher or lower than we expect. If needed, changes will be infrequent and announced in advance.

Each non-production site will also be able to use at least one gigabyte of bandwidth per day without being charged extra.

Production Sites ($0.05/day)

Production sites are the closest equivalent to current sites. As such, there’s not much to say about them. They will have full access to all features and realms, support static and dynamic content, and may be used for any production or revenue-generating purposes. There is no restriction to the number of them you can have. They may have some ability to opt into future tests, but that ability may be limited.

Although we won’t require it, we strongly recommend that if you are generating revenue from a production site, you should have a subscription membership. The cost is very small and if there is real money on the line then being able to ask for our insight and help when there’s a problem can be invaluable. It’s a good investment in your own success.

Each production site can use at least ten gigabytes of bandwidth each day without being charged extra.

Critical Sites ($0.50/day)

This is a new category of site available only to subscription members. It reflects a generalization of an informal arrangement we have with a few of our existing members who have sites that need special monitoring. This service is for sites that are particularly sensitive or important, sites that aren’t for the business, sites that are the business.

The higher price includes a custom entry for the site in our network monitoring system. That notification can be set to alert you, us, or both, in the event of a disruption. (We do reserve the right to adjust how vigorously it notifies us based on the frequency of monitoring events that result from issues determined to be under your control.) In the event of a disruption to our service, we will use the additional monitoring to ensure that service is restored as soon as possible.

Also, with critical sites, if we detect an issue, we will be able to devote more effort to investigating what’s going on to see if there is any helpful information we can proactively provide to the site operator, or if there is anything we can do on our end to help restore proper operation.

This doesn’t change the fundamental do-it-yourself nature of our service, nor will it keep sites online if they are hacked or compromised. To give an example, if we detect a WordPress blog is compromised, we disable it and our system sends out an automated notification via email to the site operator to let them know to take care of it. If that site were a critical site, we would still have to disable it, but we would send out a manual notification instead, including whatever information we can find about what’s going on, and if it were agreed upon in advance, we’d be able to alert the site operator by SMS as well.

If your site is vital to your business or generates enough revenue that you feel that a little extra attention is worth it, this is the option for you.

Each critical site can use at least 100 gigabytes of bandwidth per day without being charged extra.

General notes on site types

All site types will have full access to static and dynamic content, daemons, scheduled tasks, TLS, the ssh command line, and many other crucial features for modern sites.

With respect to bandwidth usage, each site type specifies an amount per day that won’t be charged, and that amount says “at least.” Officially, the policy is that usage in excess of the stated amount will be billable at the flat price of $0.10/GiB. However, right now, we don’t actually plan to bother keeping track of that. The goal is to cover our bandwidth costs, which are driven by attacks, not regular usage. If we’ve already charged you for inbound bandwidth to protect from attacks as part of the base site cost, we shouldn’t need to charge you again for outbound bandwidth because it’s already been paid for. So as long as site charges cover the bandwidth costs, as we expect them to, we can hold off on charging for overages. Naturally, if a site starts to use so much bandwidth that it’s becoming problematic, we’ll deal with it, but for now I kinda want people to give it their best shot.

The other “catch” is that it will be possible to upgrade sites to a higher plan, but it will not be possible to downgrade to a lower plan. Once a site is upgraded, that upgrade is permanent. Likewise, the daily costs will continue to apply even if the site is disabled.

This change will become effective for new sites on November 1st. At that time, existing sites will remain unchanged, but will be charged as Non-Production Sites. The option to choose a plan will be available in the UI on that date.

Starting December 1st, all existing sites that have not chosen a plan will be treated and billed as Production sites, but they will still have the option to make an initial plan selection. (So if you don’t get to this before the deadline, you’ll still be able to choose Non-Production for existing sites.)

Resource cost reductions

CPU and RAM resource charges for all site types will also decrease dramatically, from 17.22 RAUs per penny to 44.64 RAUs per penny. That’s a decrease of over 60% and will apply to both MySQL and sites. It should help make hosting larger, more active sites more affordable.

The pricing for storage resources will remain unchanged for now. The reliability of our current storage has been very good, but the cost (to us) is really high in terms of both TiB/$ and IOPS/$, and that shows through in the pricing (to you). We want to bring this down, and if we can stop spending every penny we have on bandwidth, I believe some more R&D in this area will really pay off.

Domain Registration

Since 2006, we’ve used the services of a third-party company to offer domain registration. That worked out really well for many years. Then, in 2014, that company was acquired by another, much larger, company. Its new parent owns a large number of other hosting companies that compete directly with us.

Initially, things were fine. But over the past twelve months or so, there have been a few incidents where our customers didn’t get the quality of service we expect. We’re concerned that it will be increasingly problematic to outsource such a critical function to a company that is essentially owned by the competition. Not to mention our lack of control over things that are very frustrating to us and our members, like “monetization*” of expired domains, is getting pretty old.

Unfortunately, the other wholesale options in the industry really aren’t any better. To make a material difference, we need an ICANN-accredited registrar. That’s a complex and expensive undertaking. To that end, we’ll need to raise prices on domain registration, first to fund the accreditation effort, and then to meet the additional ongoing requirements ICANN imposes on accredited registrars in a way that will provide a quality of service that both we and our members will be satisfied with.

The fixed costs of operating a registrar are particularly burdensome for smaller companies like ours that can’t amortize those costs over millions of names, especially if we don’t want to get any “monetization*” on us. Accordingly, we will raise the price of all domain registrations by $1.00/year on October 1st and use that money to pursue domain registration independence.

*”Monetization” is a technical term used by the domain registration industry that means “we’ll do anything, however scummy, if there’s money in it.” It’s never a good thing and it has to be handled with scare quotes because if you get any on you, the smell never washes away.

Enforcing our Terms & Conditions of Service

Our Terms & Conditions of Service are some of the shortest and easiest to comply with in the industry. Over 99% of our members are happy to do so. But the ones who don’t are getting to be a real source of hassle and frustration for us. People don’t follow our policies, they create a jam for themselves, and then they invariably expect us to fix that jam for them. And we have enough members that even “less than 1%” is enough people to cause a steady stream of headaches.

Unlike, say, DDOS attacks, these are avoidable problems that people absolutely did bring on themselves, and for which they alone should bear the costs and consequences. That’s not currently the case. You’re paying for their mistakes.

Effective immediately, if we detect the following situations, we will apply a $50.00 fee (per incident) to cover the cost of having our staff clean up the mess and advise the people involved on how our service works and what they should be doing instead:

• One person who has multiple memberships. We will consolidate the multiple memberships into one membership with multiple accounts. (Definitely do not create multiple memberships trying to get around the per-membership limit on non-production sites!)
• Multiple people sharing access to a membership. We will reset the password, get ID and a promise not to do it again from the named member, and provide references to documentation on how to use our powerful account sharing features.
• Memberships that have been transferred from one person to another. We will require the recipient to transfer the membership back to the named member or, if we are unable to establish who that is, have the person create a membership in their own name, pay the $50 fee, and then we will transfer any accounts on the invalidated membership to the new person.

Pretty much, unless you’ve done something it says in bold print not to do on our signup page, you should never see this fee. But we’ve got to get the people who think they are exempt from what few rules we have to either straighten up and fly right or find some other host. Really, we’re fine with either choice.

If you are currently doing one of these things and we haven’t caught you yet, you will have until December 1st to take steps on your own to resolve the issue. We will waive the $50.00 fee if we learn about a violation from your good-faith effort to correct it. (E.g. if you request a transfer to consolidate your two memberships before we find out about it, we will process the request without applying the fee if it is submitted before December 1st.) If you need our help to resolve the issue before then, you’ll need a subscription membership, which is a much better deal than this fee.

Final thoughts

It’s very likely as a result of these changes, members paying more than a few dollars a month will wind up paying less, possibly substantially less. They’ll probably be very happy. But there aren’t very many of those.

There are others who will be able to make a few changes to consolidate usage and keep their costs about the same. Our per-alias site root feature may be particularly helpful for people with large numbers of static sites.

But, taken on a purely percentage basis, these changes are a large increase for many people. In many cases, that increase will be from pennies per year to dollars per year. Some of them will see the value in taking these steps and will be happy to pay more to support them. Some people… won’t.

For those who need it, it’ll still be possible to host a site with us for well under a dollar a month, and while that option is not without tradeoffs, that site will in many cases be able to do more than it could in the past.

For those who can afford it, and those who want us to support their business, we’re asking them to do a little more to help support our business in return.

A fair amount of this change is motivated by the inescapable truth that offering service at the price we’re offering it increasingly requires making compromises on the quality and future viability of our service. We’re not willing to do that. I have always believed that we are about offering a good value rather than the lowest price, and these changes reflect that goal.

For people who would prefer to accept those compromises to get the absolute rock-bottom price, there are and always will be providers who are willing to make them. But we are already farther down that road than I am comfortable with. I don’t like it here, and I don’t like what I can see ahead. We are changing course. We hope you’ll follow the new path with us, but if not, we’ll definitely understand.

More power & more control.

Ever since we started, one of the inviolable limitations of our service is that we don’t let you run your own persistent processes. No more! Using the technology underpinning our NFGI PHP implementation, we’ve added support for configuring and controlling persistent processes from our member interface. These processes run as part of your web site, and when you’re not around, our system takes care of them. For example, it keeps an eye on them and can restart them if they exit.

There are two main uses for this feature.

First, although we support a huge variety of languages for web development, unless your favorite language is spelled PHP then you were stuck running it as a CGI script. For any kind of modern web framework, that causes some substantial performance problems. Ruby on Rails, Django, Catalyst, Node.JS, Network.Wai? Sure, technically you can run them here, but it’s not what you’d call a good idea.

Take that long-standing well-known fact about our service, and pitch it straight into the trash. We’ve built a new server type that can delegate incoming requests to the web application server of your choice running as a persistent process. This currently supports HTTP, FastCGI, or SCGI. (Although it’s not clear that anyone actually uses SCGI.) You can even mix-and-match technologies on different paths of the same site. Or with HTTP, you have the option to take advantage of our Apache-based infrastructure or to bypass it entirely for maximum speed and control. (Either way our edge network will still have your back, accelerating static content and protecting you from a variety of web ne’er-do-wells, so you can focus on your app.)

Second, there’s no requirement that your persistent process be a web app. Although nothing but web apps will be accessible from outside our network, from inside our network, you have a lot more flexibility. Want a private memcached instance to turbocharge your site? You got it. Redis? Check. PostgreSQL? Now possible.

This feature is going to go through a very brief open beta period for a couple of weeks; we want a bit of a slow start because trying to anticipate all the creative things our members will do is simply impossible, so we want to keep a close eye on the first handful of setups to see if anything needs tweaking.

During the beta, persistent processes will only be available on the proxy site type. If that’s not what you need, but you still want to try this out, you can always set up a process on a proxy site and talk to it from another site hosted here. Or you can just set up PHP-FPM.

To get in on this now, just log in to our member interface and submit an assistance request. We’ll convert the site(s) of your choice and you can take it from there; These features are fully implemented and integrated into the UI. Just start by setting the server type of your site to “Custom” or “Apache 2.4 Generic” and the Proxy and Daemon management options will appear on the Site Information Panel.

As this comes out of beta, watch our blog for a series of tutorial articles demonstrating how to use this feature in conjunction with various technologies.

Although it might seem like it at first glance, this does not turn our service into a VPS. We (still) have no interest in going down that road. This feature is immensely powerful, but it doesn’t include root access and can’t make anything but web services available over the Internet. If you want to run an email server, voice chat server, or game server, you’ll still need a VPS for that.

This is designed as an alternative for people running web sites who might have felt forced to move to a VPS or dedicated server in the past to get more flexibility (at the cost of all the 24×7 administrative headaches that come with it). Like all of our services, it’s pay-as-you-go and fully managed, which means that we’re the ones keeping all that infrastructure up-to-date, secure, tuned, and running. You just do what you do. We’ll take care of the rest.

More insight.

One of our most common requests that has always had a technical barrier is getting you better visibility into the resource usage of your site. We’ve now been able to add an interactive Javascript chart that shows up to two weeks of RAM & CPU usage for most currently-supported server types (all the Apache 2.4 + PHP site types and the new proxy-based server type).

As part of this change, we’ve introduced a new internal tracking system that can take resource measurements on a per-site basis for a bazillion tiny sites without collapsing under its own weight. Naturally we’ve applied that directly to our resource-based billing. So if the random sampling element of our resource billing made you uncomfortable, just make sure your site is using one of the above types, and your usage will be calculated using the new, deterministic method.

In the future, we hope to expand on this functionality to gather and report more statistics about your site that will help you explore and optimize your site’s resource usage.

Less cost.

Our resource-based billing has been a huge success. Between the economies of scale associated with the popularity of this model and the slow decline in the cost of hardware, we’ve been able to greatly reduce what we charge for resources. The cost of a resource accounting unit (RAU) has dropped from 3.25 RAUs = $0.01 to 10.59 RAUs = $0.01. That’s almost a 70% drop. You don’t need to do anything to take advantage of this; it’s automatically applied to all resource-billed sites. This change means that over 2/3rds of resource-billed dynamic sites (and well over 99% of static sites) now pay less than $0.01/day for their resource usage.

These are all great changes. They will make more power available to more people for less money. But these changes are all steppingstones. Each one can be improved, extended, enhanced. And that’s not all. We’ll have more good stuff for you in the coming months. But now, we get to my favorite part, where we hand this stuff to our members and see the amazing things they’ll do with it.

Updated 2014-11-16: The daemon and proxy features went out of beta a few weeks ago with almost no fanfare. We’ve updated this entry to reflect the non-beta setup process; also be sure to check out the first in our how-to series about these features, which covers Django.

• Bandwidth pricing has been radically revamped (downward)
• Storage pricing has been slightly tweaked (downward)
• Revamped membership security settings (2-factor authentication, SMS, and more)
• New options to control how long accounts and memberships are retained.

Read on for full details.

Bandwidth Pricing

Our costs for bandwidth are changing; as we add bandwidth, the average cost goes down but the total cost goes up. So the more we add, the more we need you to use; we pay for it whether you use it or not. So this seems like a great time to drop the price. But as much fun as our declining bandwidth pricing has been, it covers such a wide range ($1.00/GiB all the way down to under $0.20/GiB) that it’s tough to adjust in a way that makes a meaningful difference. It doesn’t help that if you just look at the headline ($1.00/GiB) we look ridiculously overpriced even though basically nobody who uses enough bandwidth for the cost to matter pays that price. So we’re doing something very different.

We’ve dropped the baseline price to $0.25/GiB. And now there are two different ways to bring the price down more, to as low as $0.15/GiB. The first discount is very similar to the old one. The price goes down by the base-10 logarithm of your account’s total bandwidth transferred (in GiB), up to $0.05 after 100,000 GiB (ever, not per month). The second discount is even simpler, the price of bandwidth for all sites on your membership goes down by $0.01 for each year your membership his been open, up to $0.05 after 5 years. As with the old pricing plan, we’re not afraid of fractional pennies, so you don’t have to wait a whole year or order of magnitude to see this take effect.

The net effect is a steep decline in the cost of bandwidth. Now, according to economics, that should cause the quantity of bandwidth demanded to go up. And if that happens, we should be able to bring the price down even more. It’d be pretty cool if we could make a regular thing out of that.

Storage Pricing

We’ve revamped our public site to document our plans that bill for bandwidth, storage, and resource usage to bring them into line with the options we offer. As a result, our resource-based billing plans are now the default, bringing their 10x cheaper storage costs with them. But that left us trying to write “$0.01/10-megabyte-days” all over the place. That’s really awkward. So we decided to make it $1.00/gigabyte-month. Since we’re from the church of 2^20, that means a 2.4% price cut on storage on all of those plans. Don’t worry, if you don’t like those plans, the old plans with their overpriced storage and no resource charge are still around.

Membership Security Settings

Maybe you saw one or two of the recent stories about people losing their domains to social engineering of their hosting companies. We did. And while we can smugly assert that that would never happen here all we want — it just isn’t possible to call us and wheedle information about a membership out of a minimum wage support rep whose job is to provide it. But this sort of thing reminds us of how important peoples’ hosting and domains are to them. And this prompted us to ask what we could improve. We found some stuff.

To start with, we’ve added support for OATH TOTP 2-factor authentication. You can set up, for example with any Android or iOS smartphone, and generate time-sensitive one-use codes to use when you log in. Even if somebody gets your password, they aren’t getting into your membership. To keep this from becoming too onerous, you can optionally mark a computer as trusted for up to a week. And to protect yourself, you can generate one-use recovery codes (to be stored somewhere very safe) to recover your membership if you lose your 2-factor device.

Next, we’ve added SMS support. Configure an SMS number on the profile tab and we’ll be able to use it to help you recover your membership if you ever need to. As an added bonus, we’ll also use it to tell you if your account runs out of funds (or enters suspended animation — see below) and you have the option to set up account balance warnings that use it as well.

We’ve also added support for setting a security question and answer. Although this is a controversial security method — choosing a good security question could be the subject of an entire blog post, like this one — the option is there.

To consolidate all of these new options for protecting your membership, we’ve also revamped our membership recovery process. This process kicks in if you happen to lose your password and access to your member email address at the same time, or if you have 2-factor authentication configured and lose the device and don’t have any recovery codes.

We now offer a total of seven possible ways to prove you’re you. For a newly-created member, three of these methods are enabled and all three are required to recover a membership if the password gets lost. Not only can you configure the additional methods, but we also allow you to determine for yourself how many of them you will have to complete to regain access to your membership if you lose your password or two-factor device. For example, someone who is very security conscious can configure all seven methods and require five of them to recover their membership. Someone more concerned with convenience can leave the default at three and simply add a couple of the easier mechanisms, like SMS and a security question.

Account & Membership Retention

Since our service is pay-as-you-go, if you stop paying, it stops going. If you leave an account unfunded for 30 days, the associated content is deleted so the resources can be reassigned to other members. Then a few days after that, memberships with nothing left on them are automatically canceled. For almost everyone, this is good enough. But we’ve made a couple of changes to offer more options who want them.

For maximum member safety, our membership recovery policy has to apply even to deleted memberships. But once a membership is deleted, we lose a lot of the information that would be needed to prove you’re you. With our new recovery policy, it’s entirely possible to wind up in a situation where content could be recovered from our backups after a membership is deleted, but the hurdle of establishing the member’s identity can’t be cleared. To help avoid that outcome, memberships now persist for 31 days after accounts expire by default, unless explicitly canceled. This timeframe can be adjusted from the profile tab, up to one year. Note that this happens after content has been deleted. It is not a safety net, it is intended as the very last line of defense, e.g. in case you become incapacitated for an extended period of time.

For people who want to extend the amount of time content is retained before it is deleted, we have added a feature consistent with our pay-as-you-go model called suspended animation. This allows you to set a balance threshold for each account. When the account balance falls below this level, everything will stop as if the account was empty, and all nonessential charges will stop. The remaining balance will then be used to preserve the account content as long as possible. Once it is exhausted, the original 30-day grace period will kick in. To use this feature, visit the account info panel in our UI. The system will help you estimate a threshold that will protect your content as long as you want.

TLDR

To give your membership and its contents the best possible protection against attackers, financial problems, and unforeseen disasters, you can (and should) take the following steps:

1. Enjoy bandwidth pricing drop. It’s automatic. (Also: Use more bandwidth, so we can lower price even more!)
2. Set up 2-factor authentication.
3. Generate 2-factor recovery codes, and put them somewhere very safe (encrypted safe storage, or printed out and kept in an actual safe).
4. Set up SMS.
5. Customize your recovery settings.
6. For your account(s), set a suspended animation threshold that will protect your content long enough for you to feel comfortable in 99% of cases.
7. Set a retention period for your membership to cover that 1% disaster scenario.

I wanted to put the technology change first, because it’s way more interesting and affects a lot more people, but I know pricing changes always attract the most attention, so I will start there instead.

Traditionally, we have avoided charging for space used by MySQL processes. Most processes are very small, and there simply wasn’t enough usage or problems to merit hassling people for a few extra pennies. Unfortunately, that’s no longer true. We need to take steps to either rein in a few cases of excessive usage or recover enough money to cover the costs of the resources we must allocate to them. Here are some of the numbers:

• The median size of a MySQL process is about 5.2 megabytes.
• Over 90% of all MySQL processes are less than 40 megabytes in size.
• For the first time in our history, the top 5 MySQL processes are all over 10 GiB in size.
• The largest 10 (not 10%, just 10) of MySQL processes use almost 34% of the total space.
• The largest 1% of MySQL processes use almost 65% of the total space.

Something is wrong if two people are paying the same for MySQL but one is using (literally) thousands of times more than the other. And obviously we need to fix that. But we need to do that in a way that has absolutely no impact on the people (i.e. almost everybody) whose usage is both reasonable and within our expectations.

In order to ensure that we don’t negatively impact people unnecessarily, we have taken the 90th percentile size (40 megabytes) as a cut-off point. If your usage is less than that, nothing about your MySQL pricing will change based on space used. If your usage is more than that, then on September 1st, 2012, we will begin charging an additional fee of $0.002/MiB-month for MySQL storage over 40MiB per process. This will be calculated and billed exactly the same as site storage currently is, except that it is five times cheaper, and the first 40MiB of space used by each MySQL process will be exempt.

In addition, there is also a second pricing problem we need to solve, which is heavy database I/O loads. This problem frequently goes hand-in-hand with large processes, because with small ones a little inefficiency is typically too small to notice. We have noticed that occasionally some databases run into problems due to poorly-optimized queries (i.e. missing or inefficient indexes). For example, we have seen a couple of places where a site depends on a MySQL query of a large table with no indexing that results in large temporary tables being written to disk. This takes ages — a good rule of thumb is that if your query is writing temporary tables to disk, you’re doing it wrong — and so requests from that site start to pile up, and you wind up with the MySQL process trying to write the same huge temporary tables to disk 8 or 10 times at once. This is so intensive that in our shared hosting environment, other people’s processes start to suffer because disks only spin so fast and they’re starving to death waiting for their turn. Of course we act promptly when these conditions occur, and since they are almost always the result of poor optimization, they are typically easily for the member to resolve once we bring it to their attention. But occasionally we get a response like “why should I?” and unfortunately we need an answer to that question. Therefore, effective September 1st, if we determine that a process is using a disproportionate amount of I/O and the responsible member is unwilling or unable to resolve the issue, the fee for MySQL storage will apply to the whole process (no 40MiB exemption), and will be set to a higher rate as determined by us as necessary to cover the cost of resources being used. This will give us some flexibility to support larger MySQL requirements than we currently can with the current one-size-fits-all model. We will, of course, retain the option to refuse service to use cases that we find truly abusive or unsupportable on our infrastructure. Please keep in mind that this change will affect the pricing of about five MySQL processes. (Again, not 5%, just 5.) So if you’re worried that this will affect you, it almost certainly won’t, and we will contact you individually (if we haven’t already) before it does.

So, to sum up the pricing changes:

• Less than 10% of our MySQL-using members will see pricing changes.
• People who are affected are using dozens, hundreds, or thousands of times more resources than everybody else.
• Of the affected 10%, most will pay a few cents a month more and about 75% will pay less than $2.00/month more.
• MySQL processes using more than 40MiB of space will be charged $0.002/MiB-month for the excess.
• We will be able to set custom pricing for MySQL processes with unusually intense I/O needs.
• These changes will go into effect September 1st, 2012.
• This will improve MySQL performance for everybody by creating incentives not to waste resources and by allowing us to use money collected from heavy MySQL users to allocate more resources to them, so they have less effect on everyone else.

With the pricing stuff out of the way, I want to move on to the other part of the announcement. After all that, we’re getting rid of MySQL! Well, OK, sort of, but not really.

We are going to start moving from MySQL 5.0 to MariaDB 5.3. NearlyFreeSpeech has been around long enough that when we started offering MySQL, it was “owned” by its own open-source friendly company. Later in its life, it was acquired by Sun, and things started to get a little weird, leading to a number of releases that in our opinion were of very poor quality and thus we never adopted. Then, to make things worse, Sun was then acquired by Oracle. This has had a number of negative influences on us, as we have depended on both OpenSolaris and MySQL in the past. In our opinion, for a variety of reasons, Oracle is not a good entity for us to have external dependencies on. We feel their handling of the open source community has left a lot to be desired, and that their support for MySQL has continued in the wrong direction.

Fortunately, as a project with roots an open source, MySQL has options and alternatives. The one we have chosen to pursue is MariaDB. This is a fork of the MySQL project by the original creator of MySQL, Monty Widenius. It uses some of the original code, some replacement code which is much better (e.g. it uses XtraDB, a drop-in replacement for InnoDB), and has (in our opinion) better features and quality control than Oracle’s MySQL releases. This will not only improve performance, but also let people take advantage of a lot of newer MySQL features that aren’t available in the 5.0 release series. There have been huge improvements to stored procedures and functions, for example.

We’ve been running MariaDB 5.3 as our core internal database for awhile now, and it’s done very well for us. And, more good news, moving to MariaDB 5.3 from MySQL 5.0 doesn’t require the clunky system table upgrades that 4.x to 5.0 did. You won’t have to do anything to take advantage of the change, and everything will continue to work just like before, except faster and with more optional features available for those who want them. However, we will also be taking this opportunity to rebuild all of our MySQL nodes with the freshest OS and software updates and additional resources allocated. This will require brief downtime (typically about 5 minutes) for each MySQL process as we migrate it from an old node to a new one.

These upgrades will be on a node-by-node basis, and we will preannounce the moves on Twitter. You can see what node your MySQL process is using at any time in our member interface. For example, the first new node (which is currently out of service) is m2, and the first move will be from old node m1 to new node m2, and we hope to announce that in a couple of days. Then, once m1 is empty, we will take it offline, rebuild it, and announce a migration from another node to that one. Then repeat the process on down the line until everyone is on the new hotness.

There are still 54 MySQL processes running on an old MySQL 4.x node (m6). Extended support for MySQL 4.x ended in 2008. It’s 2012, so we’re going to go ahead and push those processes through this upgrade. The processess should continue to work, but will require those members to upgrade their system tables as described in our FAQ before using their process with phpMyAdmin or changing any usernames or passwords in the future. We strongly urge those few people still using MySQL 4.x to avail themselves of our free “Upgrade MySQL 4.1 Process” assistance request to upgrade to MySQL 5.0 at a time of their choosing rather than waiting for an involuntary upgrade.

Update: While converting everyone to MariaDB, we found a way to reduce the per-process overhead, bringing the median process size down to 3.25 MiB, and the 90th percentile down to about ten times that (32.70 MiB). Despite this, the base space allocation will remain at 40MiB — it’ll just give everybody that much more headroom.

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.