NearlyFreeSpeech

NearlyFreeSpeech.NET was founded with no intention of ever turning a profit. There are no investors to pay off, no debt to service, and no short-term-focused shareholders measuring ROI with three-month horizons. NearlyFreeSpeech.NET exists because I want to provide as many people as possible with affordable hosting free of "big company" restrictions that come from pleasing investors, debtors, and shareholders. Therefore, all the fees we charge are designed to cover the costs of the resources it takes to provide the service. 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.