Due to our load-balancing capabilities, most of this will be done with no disruption to our services. There are a few exceptions, though. We’ll be doing maintenance over the next few days in the early morning hours (between 1am and 5am US Eastern time — 5am and 9am UTC), the following services will be briefly disrupted (should be about 5-10 minutes each):

Tuesday Morning
- www.nearlyfreespeech.net
- members.nearlyfreespeech.net
- various error pages
- Member MySQL Node m9

Wednesday Morning
- Our email (e.g. support@nearlyfreespeech.net)
- Outbound mail sent from CGI scripts
- Member ssh & FTP
- phpMyAdmin server
- Email forwarding
- Member MySQL Node m4
- Member MySQL Node m6
- Member MySQL Node m7
- Member MySQL Node m8
- Member MySQL Node m23
- Member MySQL Node m25
- Most pools (a beta feature in limited testing — you know if you have one)

Thursday Morning
- Member MySQL Node m1
- Member MySQL Node m10
- Member MySQL Node m11
- Member MySQL Node m12
- Member MySQL Node m13
- Member MySQL Node m14
- Member MySQL Node m15
- Member MySQL Node m16
- Member MySQL Node m17
- Member MySQL Node m18
- Member MySQL Node m19
- Member MySQL Node m20
- Member MySQL Node m22
- Member MySQL Node m24
- Member MySQL Node m26

To reiterate, these disruptions will be very short (<10 minutes); you probably won’t even notice them, but we wanted to let you know what’s going on anyway. Although it’s only a few minutes, we’ll be changing a lot of stuff under the hood, which is an important step in helping us build a more reliable network.

We wish it were possible to build a network with 100% availability, but we’re still working on that. In the meantime, this scheduled maintenance should definitely help us get a little closer.

Thanks!

Effective July 1st, the new price for domain registrations, renewals, and transfers will increase from $8.59/year to $8.99/year.

Get your domain renewals in now to avoid the increase.

These changes have nothing to do with us, are not under our control, and are of no benefit to us. They’re bad for us, and they’re bad for you. Unfortunately, the same (auto-renewing into perpetuity) contracts with ICANN that grant Verisign a monopoly over .COM, .NET, and .NAME domains (among others) enshrine Verisign’s right to unilaterally raise prices by 7% every year, and they never miss a chance to do so. Their 30% profit margin in 2009 will almost certainly increase after they finish unloading everything not domain-related onto Symantec. It’s not bad work if you can get it. (And live with yourself afterward.)

Pool vs. VPS

I’m really trying to avoid saying “it’s like a VPS” although it shares DNA with that approach: isolation by virtualization, resource guarantees, and scalability. Because despite those similarities, it’s equally notable for its differences. Like our traditional service, and unlike a VPS, pools take advantage of our core infrastructure: firewalls, HTTP accelerators, and high-performance file servers. Also unlike a VPS, pools include our 24×7x365 operational monitoring and maintenance of the OS, network stack, and software environment.

It’s not as cut and dried as saying “Pools are better than VPSs,” or the other way around. In keeping with our “we host web sites” mantra, Pools are extremely optimized for awesome hosting of web applications; they don’t really do anything else. For hosting the world’s Ventrillo, Shoutcast, IRC bots and servers, and all that other stuff, a “typical” VPS is still the only way to go, and we’re grateful that other people offer that service, because we have no interest in doing it.

There are a couple of key factors to look at to determine whether you’re better off with a pool or with a VPS.

Is it a web (port 80) application?

Yes -> Pool

No -> VPS

You want:

Root access and maximum control over OS choice and tuning. -> VPS

To focus on your site and leave the security updates, firewalls, and midnight outages to a team of experts. -> Pool

You need a dedicated IP address or SSL support:

Yes -> VPS

No -> Pool

Pool Pricing

(As with all things beta, the information here is subject to change as we refine what we can and can’t do.)

Pools are priced based on RAM, but include both a RAM and CPU component. (The difference being that CPU usage is burstable and RAM is not.) The specific CPU amounts are still be determined, but the minimum reservation will, somewhat obviously, be proportional to the ratio of Ghz to GiB in the standard blades we use. We inevitably run out of RAM before CPU power, and we don’t expect that to change, so the “burst” CPU amounts available should be substantial.

The base price for a pool is $3.43/month. Each gigabyte of RAM is $21.45/month. That means you can get a 1GB pool of dedicated RAM for less than $25/month.

However, since this is NearlyFreeSpeech.NET, all “monthly” charges are based on 31-day months and calculated to the penny in real time.

Pool Sizing

There are no packages or bundles. Pools can be configured at any memory size you desire between a minimum of 128MiB ($6.11/month) and a maximum of 3GiB ($67.78/month) in 4mb increments, and the memory size can be changed at any time with a simple “reboot” that takes about 20-30 seconds.

There is one “catch.” When sizing your pool, keep in mind that there is some overhead. There is baseline OS overhead of about 40MiB plus about 8MiB per GiB. (We could theoretically do a 64MiB pool, but the overhead would leave about 24MiB available for your web server. So it’s technically cool, but not terribly practical.)

If you’re not sure how much memory you need, we recommend starting with 128 MiB ($6.11/month) or 256 MiB ($8.43/month).

Storage Pricing Offset

As most people know, our charge for disk storage is how we have traditionally recovered the equipment costs (including CPU and RAM). Obviously pools represent a very different approach, and it would be “double dipping” to charge both fees at the same time.

Thus, at least for the first part of the beta, 90% the storage charges that accrue for sites that are assigned to pools will be used to offset the cost of the pool. For example, if you currently pay $5.00/month for storage for your site example, and you convert it to a pool, you will get up to a $4.50/month offset against the cost of the pool.

That’s not the long term solution to making storage pricing more fair, it’s more of a band-aid. We will be adjusting this down the road.

Pools and Lanes

It’s possible to run more than one site inside a pool. Pools can be divided into multiple “lanes,” each of which can host a completely separate site. (Picture competitive swimmers and the little floaty things that separate their lanes.) Sites in different lanes of the same pool share the RAM and CPU of the pool, but have “logical” isolation; they cannot interact or see each other and might be running completely different configurations or web servers.

Apache Lanes

We provide an Apache 2.2 build that works great with pools. It comes with PHP 5.2 and 5.3 support available, both of which run with safe_mode off and at a significant performance boost over PHP Fast. It’s great for heavy frameworks like Zend and provides a particularly nice boost to hard-hit sites running CMS applications like Drupal.

But not only is it faster than PHP Fast, it’s also more flexible than PHP Flex. You get full control over your httpd.conf and php.ini files. Need custom PHP extensions? No problem. Want mod_ruby or mod_perl instead? No problem. Add what you need. Want mod_deflate or mod_dav? You can make it happen.

Arbitrary Server Lanes

What if you don’t want to run Apache at all? Still no problem. Inside a pool, it is possible to run any web server or application. Zope, Rails, Catalyst, Tomcat; pretty much anything that talks HTTP on port 80 will work. The only restriction we impose is that it has to be able to run in “foreground” or “monitored” mode. (That’s just so that our system can keep an eye on it and make sure it stays running.)

How do I get in the beta?

We have added an assistance request for the Pool beta. The initial allocation of resources for the beta will be limited, and since pools represent a resource reservation, beta opportunities may be limited as well. We will get as many people into the beta as quickly as we can, but we may have to delay some requests if it proves too popular.

The Future of Pools

Initially, at least for the duration of this beta, pools will be most suitable for larger sites due to the nontrivial per-pool overhead; it’s not shared hosting and can’t be priced that way. However, part of the purpose of the beta is to help us finalize the development and testing of the underlying technology to get it to the level where we can offer a related option that will make it cost-effective for even very small sites to get the security, performance and flexibility offered by pools.

This is really exciting stuff for us, and we hope you’ll check it out and help us make it even better, both by giving us beta feedback and by using it to do amazing stuff we never would have thought of.

Most people clear up overdrafts right away. But, sadly, there are exceptions. And, as a result, losses from unrecovered RespectMyPrivacy overdrafts surpass every type, even credit card fraud.

So if we let people prepay for RespectMyPrivacy, and give them a discount for doing it, everybody wins. If you’ve got a domain with privacy, you can prepay it at any time from the domain info panel in the member interface.

We’re NearlyFreeSpeech and we do things a certain way; RespectMyPrivacy is built to respect your privacy, not to lock you in. Prepaying preserves that promise. If you abandon the domain, transfer it elsewhere, or cancel privacy service, you’ll get a credit back based on how much prepaid time is left when RespectMyPrivacy comes off.

I think this is a pretty neat change, and I hope you will find it useful.

Next up, a welcome change to inbound domain transfers: if you’re transferring a domain into NearlyFreeSpeech, and you find out after placing the transfer order that you’ve got a bad admin contact address or an uncooperative privacy service on the domain, you’ll get stuck at the “waiting for admin contact approval” step. In the past, you had to buy support points and open an issue to get us to go through a tedious manual process (hence the support points) to cancel the transfer.

You can now request the transfer be canceled via the member interface, and it will happen within a few hours without any of the support cost or hassle. This is a really nice change for the people affected, and I’m glad the technology has finally become available to let us implement it.

Third, if you have unused support points and no open issues, you can now easily cash the points out to any of your accounts just by clicking the appropriate action on your account’s info panel. We’ve always done this on request at no charge, we just wanted to streamline the process.

Fourth, you can now customize the Apache ServerAdmin property (used to display a site administrator email address in response to certain types of site errors) from each site’s panel in the member interface.

Finally, a small tweak to how we do support issues. After we phased in the “support points” concept, we added an undocumented option for people to open support issues before buying support points in order to have us “triage” the requests and see if they were suitable for paid support. That was always intended to be a transitional feature while we felt out the new system, but it has certain use cases that cause problems.

It’s hard to explain the problems without giving examples that would compromise people’s privacy. But sometimes people phrase issues in such a way that telling them it’s out of scope looks and feels like cruelly refusing to help them, but telling them that they need to buy points to proceed creates a false expectation that doing so will get them something it won’t. Neither option really works for me.

So, since we’ve felt out the new system and we’re generally happy with it, and to avoid the problem cases, we’ve dropped the undocumented triage option. If you have any questions about whether or not an issue is appropriate for paid support, please ask in our forums. We’ll be happy to triage it there, where we’re not limited to yes or no answers. And, as is often the case, if the question can be answered for free in our forum we’ll have that option available as well.

That’s the end of the upgrades (for now), which brings us to Twitter. We’ve been talking about using Twitter as a venue for to announcement small things more frequently, like technology betas and some of these UI upgrades that don’t necessarily merit blog posts of their own. It won’t replace our offsite status page or anything, just minor stuff that people might want to know about.

But I was appalled when I went to sign up; Twitter cut me off at “NearlyFreeSpeec!” I tried “nfsn” but it seems one of our members set that up as a “Fan-made, unofficial account for one of the most intersting & forward thinking webhosts online.” If that (awesome) fan is out there and would be willing to let us take over that name, please let me know.

Thanks everyone!

That’s all been prepped now, and what we’re going to do is automatically migrate everyone during the month of April. If you have affected sites, you can get a specific time for each site from our member interface, and the main sites page will star any site scheduled for an upgrade on your list of sites so you can see at a glance which sites are affected.

There are two drawbacks to this upgrade.

The first is that the upgrade involves minor downtime since the files need to be transferred from one file server to the other, which requires log files and any dynamic data files be closed and held inactive while they’re moved. The downtime will be roughly proportional to the size of the site, so this is a great time to peek in and check for any files you’re not using or log files you want to trim; it’ll make the upgrade go faster and you’ll save money on storage.

In addition, while most sites will be moved transparently, sites that use absolute paths in .htaccess files (or in PHP scripts, although we don’t advise that) will need to be updated to work properly after the move. If this is applicable at all (I personally moved all my sites without needing to change anything), it should just take a few minutes to update.

For those two reasons, we understand that you may want some control over upgrade schedule. To that end, you can log in and upgrade any of your eligible sites at any time between now and its scheduled date. You can also postpone a site’s upgrade if the scheduled time doesn’t work for you, within reason. You can’t postpone an upgrade past April 20, and postponements are for random intervals just so we don’t end up with an unmanageable number of sites to move on April 30th at 11pm.

The target file servers for this upgrade, f2 and f5, are a lot faster, have SSD-based L2 caches for busy files, superior network performance, and never require painfully long filesystem checks after an unclean shutdown, so we think people will be really happy with the change. Oh, and they have much newer and better redundant power supply setups!

We hope that the preparations we’ve made will make the transition as easy and painless as possible, and that everyone affected will agree that the end results are well worth having.

The maintenance window will be from 10am to 4pm MST (5pm to 11pm UTC) on Friday, November 20th, 2009.

This will affect web hosting, email forwarding, and “support services” (i.e. our sites, SSH, FTP) for all members.

We don’t expect the actual downtime to be anything close to the whole time. In an ideal case, it would take us about an hour to prep and and hour to take everything down, move it, and bring it back up. However, this is the real world, not the ideal one, so we’re giving ourselves some additional room to maneuver.

I’m sure there’s someone out there for whom this is a spectacularly inconvenient time, and to them we sincerely apologize. Any time we picked for maintenance of this sort would be bad for somebody. We did strive to pick a low-usage time when we could guarantee the manpower we needed.

We also would have liked to provide more notice, but up until this evening any announcement would have been pretty much content-free. (“We will be scheduling a maintenance downtime of unknown length at an unknown point in the future.”) As of right now, we have a schedule we believe can be met (the original proposed date has already passed, so any earlier specific announcement would have turned out to be wrong), and so we’re bringing it to you as quickly as we can.

We apologize again for the inconvenience. On Friday, as every day, we’ll all be working hard to bring you the best, most reliable hosting service we can. “NEITHER RAIN NOR SNOW NOR GLOM OF NIT.”

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.

Site Canonical Names

Site canonical names and types can now be set from the member interface by selecting the “Set Canonical Name” action from the site info panel. No more waiting for support requests!

For your information…

The site information panel for each site will now display a “For your information…” box if our system detects potential problems with your site, ranging from missing favicon.ico files to insecure “public” directory permissions.

Domain transfer codes

Domain transfer codes (needed for outbound domain transfers) can now be obtained from the member interface if the domain is unlocked. Please don’t use this feature, we really hate seeing domains transferred away!

Organization-owned accounts

Accounts can now be held in the name of an organization, such as a business, NGO, or club. This is designed to complement role membership, but should be useful for web developers hosting one or more business customers’ sites as well.

Alternate Emergency Contacts

The unintended consequence of having as draconian a privacy policy as we do and enforcing a strict 1:1 relationship between memberships and people is that we’ve had a couple of gut-wrenching cases arise where a company’s domain expired and their regular webmaster, who manages their account with us, was not available for whatever reason. In such situations, people tend to wind up screaming us about service interruptions we’re obligated not to talk to them about.

To help address that, you can now appoint an “alternate emergency contact” on a per-account basis. This is someone who can step in and take a limited subset of actions, like renewing a domain or depositing additional funds to keep a site running, if you’re unavailable. Finally, all our members managing their company’s or customers’ websites can go on vacation! (See our member FAQ for complete details.)

phpMyAdmin

phpMyAdmin has received a significant version upgrade. In addition, we have changed the way we interface with it so you can now use it to connect to MySQL processes other than your own. So if you’re managing MySQL for a friend, you no longer need to maintain a private copy of phpMyAdmin. (Naturally this feature will alert us if someone attempts to abuse it.) phpMyAdmin has been moved up to the main MySQL tab in our member interface since it is no longer process-specific. It’s now also possible to directly bookmark the phpMyAdmin login page if it’s something you access frequently.

Please note the “exit / log out” option in phpMyAdmin is very thorough; it will log you all the way out of our member interface! Click our logo in the upper left instead if you want to escape phpMyAdmin but remain logged in.

That’s all… for now! These are small things, but they represent the tip of the behind-the-scenes changes we needed to do to make certain longstanding feature requests able to work in our interface. Hopefully they will also improve the member experience a little bit while we get that finished up.

Our system still works with PHP 4, and we still have about 32.5% of our active hosted sites running on PHP 4. But its days are clearly numbered, so we’re taking appropriate, measured steps to curtail PHP 4 support on our network as well. We’ve removed most public references to PHP 4, and using our interface it’s no longer possible to switch a site to PHP 4, only away from it. With that done, we’re not making specific plans to go out and yank PHP 4 out from under our members whose sites are still using it before they are ready.

However, our plans are not the only factor at work. Sooner or later, a security problem or critical bug will emerge with PHP 4 that we won’t be able to fix ourselves or work around. Without developer support, we’ll be out of options. So the same day that happens, every PHP 4 site we host will be upgraded to the then-current version of PHP 5 whether they’re ready or not.

We have no way to predict if or when that will happen. Therefore, if your site is running PHP 4, you should make plans to upgrade your site sometime soon at a time when you’ll be available to handle any issues that arise. The upgrade is pretty straightforward, and problems are fairly rare, but it’s still better to block out a bit of time just in case.

To help people make this move, I want to address three points.

1. What version of PHP is my site running?

To find the version of PHP used by your site, go the site info panel for your site (click on the site name on the Sites tab), and look for the Server Type line in the Config Information box. If it says “Apache 1.3, PHP 4 Fast, CGI” then that site is running PHP 4. If it says PHP 5 Fast or PHP 5 Flex, then you don’t need to worry, because that site is already up-to-date.

2. How do I upgrade my site?

From the same page, select the Change Server Type action from the Actions box. Select the “Apache 1.3, PHP 5 Fast, CGI” radio button, and click the “Save Changes” button. Give it about 5 minutes, and your site should be up and running on PHP 5 with negligible disruption. The actual switchover should be nearly instant, it just sometimes takes a few minutes to process. When upgrading your site, do not accidentally choose the PHP 5 Flex option; it is a special-purpose option that will cause slower performance and much bigger compatibility issues in most cases.

3. What kind of problems could I have when upgrading?

Most people won’t have any problems at all. If you’re running a prewritten application developed by someone else (e.g. WordPress), then just make sure you are running an up-to-date version identified by the developers as working with PHP 5. That’s about it.

For people who program their own sites, we do have a few tips. When we upgraded our own PHP code from PHP 4 to PHP 5, the main thing that bit us was that “public” and “protected” are now reserved words in PHP 5. So, a couple of variable names ($public) had to be changed. There’s also an HTTP extension (pecl_http) we provide with PHP 5 with some common function names that sometimes collide with names others might have used in PHP 4 (http_request, http_get); if your site uses functions with these names, they’ll have to be renamed. We encountered similar issues with a SOAP library provided by our domain registrar for interacting with their system.

There is also some ugly, ugly code floating around that redefines $this inside objects in PHP 4. That should be fixed, because it was a bad idea in the first place. We encountered it in the PEAR Net_DNS module and a couple of other similar places.

The official PHP site provides a helpful list of backward-incompatible changes in PHP 5. In addition to the main content, the comments on that page are also quite helpful.

If people have other tips for migrating from PHP 4 to PHP 5, please feel free to submit them as comments.

But please, if you have a site still running on PHP 4, update it soon, at a time of your choosing, rather than waiting until the choice is taken away.