To clarify our thinking, we're currently considering simplifying the pricing somehow (e.g., only usage fees or only a mark-up on usage fees) and we'd like some feedback on that.
Nearly a dozen people so far (38% currently) have voted for 0%. In other words, they think we shouldn't add anything to Amazon EC2 usage fees. Is that because of the monthly fee or because you don't think we should fund development this way? If so, does any one have any other good ideas?
Just in case, I've refined the question so it asks you to assume we don't charge a monthly fee.
Thanks for the feedback!
Hi, I can't see why you would think charging an ongoing fee is reasonable. The only value added after the initial up-front work is security updates. Your value is saving me up-front time. If you start charging an ongoing fee just for your security updates I will bite the bullet and build my own AMI and after I spend the time and get it configured there will be no difference of whether I used your AMI or my own. Or I can hire someone to put one together for me and be done with it. Please let me know if I have something wrong and you do continuously provide an ongoing value.
Brian, thank you for sharing your perspective on this.
First, the bulk of the security updates an appliance will receive will come directly from the Ubuntu repositories. We have no intention of "charging" for security updates. They don't even go through us.
Second, regarding the mark-up on usage fees model, there are a few ways to look at this. When you develop your own appliance you pay for the full cost of development and testing. You also have to take care of on-going maintenance (e.g., when a new version of the distribution comes out).
Depending on the application and complexity of the integration it can take anywhere between a few hours to a few days of work until everything is working perfectly. And that's for us - after having developed dozens of appliances over the last year and a half, picking up tricks and skills along the way. For a novice it may either take longer or the quality and consistency of the result will suffer. There's alot of work involved, not all of it fun.
Having each user reinvent the wheel and bare 100% of the costs himself is in my mind the worst case scenario.
In principle, what's nice about the community funded open source model is that everybody pitches in to share the burden and many hands make the load light for each individual user. If you accept this can be a good idea in principle the question now becomes how you implement it in the context of "cloud computing" where a server can run for a few hours, a few weeks or a few years.
Is it reasonable to ask a teacher that is demoing appliances for a few hours to to pitch in as much as a business that is running many appliances in production?
Also, if you "charge" up-front for the setup, that is more of a commitment and less convenient then having a small incremental charge that only adds up to something meaningful over long time periods. If you're using an appliance for a year you're probably getting more value from it then if you use it for an hour.
How about a couple of pricing model options?
I think no monthly fee but a 10% uplift on the EC2 data rates would be a great way to make sure you get a residual income and easier to sneak past 'head office' types than any kind of voluntary contribution, but perhaps also offer a $5/month/no markup option too, for heavy users?
I think the monthly fee for using your AMIs is the easiest. A flat fee to use them is about as simple as it gets. %s are great for people that do not have any volume, but once someone starts to get traffic, now you (your fees) are a variable expense that has to be monitored and determined if your services are still worth it.
I completely believe in funding products that I use, but I do not care for the model that expands based upon percentage use. My two cents.
Unfortunately, in this model monthly fees aren't a viable option, because they are per-subscription, not per instance. That means for example that a user who wants to test drive a single appliance for a couple of days would be charged the same as a large business that is deploying hundreds of appliances 24x7 in production.
I donate whenever i can and whenever I profit from any opensoure project. Sometimes, I even donate upfront to support development or bounty for a feature etc. I also click on ads if i found it's interesting and useful.
But i do NOT buy any premium version of any projects. Usually, i do not even use the product if it have a premium version. IMHO, tkl do help setting up new vm upfront. but most admin can do this by themselves and they will if they're charged for this.
Also, tkl dont help much after the system is sets up. So there's no logic on monthly charge.
But when you use Amazon EC2, you are already charged on usage, so the idea is to add a reasonable mark-up on those fees so that people who are using TurnKey give back a little bit into a pool which helps support the project and fund future development. In the early stages this won't amount to much but with thousands of users the pool could grow large enough over time to make a meaningful difference.
This is a win-win for the community because the development funds open source appliances rather than expensive and closed proprietary alternatives. To the casual user a few bucks here and there would hardly be noticed on their bill but multiply this thousands of times over and suddenly we have the resources to do much more for the project's users. I think that's in everybody's best interests.
depending on target audience realize that introducing any additional variable expense to a company is an obstacle to adoption/purchase. Businesses like to be able to budget/plan (or at least think they can) a specific amount each month. In the end it depends on what your users/customers are primarily using the images for. Is it for their (our) own use, or is it primarily to package and resell after we create the 'solution' on top of the image (i.e. specific application for end user). The former creates less of a challenge IMHO then the latter. If its resold utilizing ec2 then there is a variable expense on top of a variable expense and generating margins on an unknown will be a significant challenge for both the end user and those packaging the image.
also, and just to admit my own bias, I am not a fan of % pricing. Even if variable based on tiers, static $/mo is simply more pallatable.
I agree that variable pricing is hard for most people. A fixed monthly amount is better.
The biggest problem I see with EC2 is when they start charging for bandwidth (Which they will be doing starting June of this year according to their pricing page). Then, people are really not going to know what their monthly charge will be.
Anyhow, whether or not paying for bandwidth by usage is an issue depends on your usage case. The vast majority of web sites don't get enough traffic to use that much bandwidth anyway.
We experiment with a lot of open source projects and some but not all end up being useful to us in production. Paying up front fees is a barrier to experimentation and use. We like to support those efforts that are helping us to make money and grow our business, but choose to donate directly down the road to a projects that make life easier for us.
This discussion is about adding a fee on top of the Amazon EC2 fees as a way to help fund the project. The idea is that you have to pay something to Amazon anyway (They do not offer their service for free) so adding a small increment will not be a large impact.
TKL will always give you VM images and ISOs for free so you still have a way to try it out.
This survey asks
how much to add to AWS EC2 "usage" fees.
My first question is why tie the cost to EC2 instance costs?
AWS has a lot of variation in pricing EC2 use
then there are various costs for different sizes of compute resources
These are all priced differently by AWS.
However from an "Application Appliance" perspective there are really only two considerations (32 or 64 bit)
So should someone pay more $ to run the Appliance on the largest 64 bit machine resource than on the smallest? I'm not sure the application's configuration changes does it? So why should it cost different.
Next using EC2 "usage" ...
Remember AWS's EC2 usage fee includes your use of Elastic Block Store (EBS), load balancing, auto scaling etc. None of those additional service costs for EC2 have anything to do with the Application Appliance...
My point I guess is I'd like to better understand what the Poll Question means by AWS "usage".
If you look at Amazon's EC2 pricing page:
They have a usage fee, which is how much they charge per hour you are using one of their instances.
The poll is about adding a percentage to that fee. Since it is a percentage, it can be applied to any type of EC2 instance since they all list a usage fee.
Also, trying to reach for perfection and make everyone happy may be impossible or at least impractical. Most of all we'd like to focus on development, and that means keeping everything as simple as possible. Hence our idea for a flat mark-up percentage.
Remember the resource pool from any mark-up is essentially reinvested back into open source development which the community benefits from.
Are the images going to be available for people with their own cloud. I'm a student and systems admin for our research lab at our university and we recently built a small ubuntu cloud based on eucalyptus and it's running on 4 machines with 32gigs of ram dual quad core amd 2.7ghz processors and ssd harddrives. I have used your turnkey images and love them, and am looking to move stuff to our own cloud and thus wouldn't be paying amazons usage fees.
I haven't spent much time thinking about this, but off the top of my head I think a 5% premium sounds reasonable for EC2 images. (I'm assuming) There will always be ways to tinker/learn for free with the existing VMs and ISOs. I would only move to EC2 instances when I am planning on going "live" with something and at that point I am willing to pay for the services I need to do so -- and that, in my mind, includes the work done by the TurnKey folks.
Seems like people are overthinking this. There are other image vendors out there...what do they do?
JumpBox charges on the order of a 12 cent / hr premium.
If EC2 was free to begin with, I think an open source surcharge would be odd. Since we are already paying amazon, a small, 1-4 c / hr charge makes perfect sense. A no hassle way to keep the community going.
The above model was just announced and after reading it the approach sounds reasonable to me.
It should provide decent sustainable revenue for the developers application services.
Extra services bundled into the application systems like jumpbox or TurnKey like the described Administation Portal that lets a customer manage/configure server names, automate backup/restore, etc. for JumpBox AWS EC2 instances... can make it very worthwhile to pay the monthly fee !
I also like the approach because its uncomplicated <g>
How about contacting Amazon and negotiating a commission on every installation and every instances Zimbra is used on their cloud only when EC2 is initiated by visiting your site?
I would highly recommend you charge a single onetime fee for the images. The savings is based on the upfront work that I do not have to do if I use your image -- so, I may not mind paying you if I find your image useful. You could implement it as a code I have to enter to remove certain request for donation banner. This way, if I try it but don't like it and not use any further, I do not owe you anything.
I know Devpay does not quite allow that -- but you do not have to go through Devpay -- you can do it as a paypal donation -- and more of a honor system.
Jusr my 2c. And I wish you success.
I would like to move my 38 websites EC2 and eliminate my two dedicated servers. A few days ago I signed up for EC2 found there isn't a Freebsd AMI. Instead, I'm using a Debian Lamp AMI and already there are major roadblocks. So I started looking at fee based solutions like Jumpbox and Turnkey for my LAMP solution. I couldn't find a solution using Jumpbox, so now I'm looking at Turnkey. The problems I'm having are with my apache, php & mysql configurations and database. As you know, if the server goes down, the instance isn't persistent and all is lost.
I did make an AMI of my configured Debian Lamp AMI and stored it on S3. This works to capture my apache, php, mysql configuration and databases if there is no activity with the database. Any changes to the apache, php or mysql configurations require making another AMI. This manual process just isn't going to work for every little change I make.
I moved my databases to EBS to make them persistent. Also copied apache, php and mysql config to EBS. On a reboot or starting up the instance, I need to copy my apache, php and mysql configs back from EBS to the running instance and restart the servers to get it setup properly. A manual process.
I need to make backups of my databases and user data like uploaded images on EBS. Doing a snapshots of a live database isn't going to work. Another manual process using another tool like mysqldump or what I'm using now "Navicat".
I've read there is a performance benefit of making my EBS Raid 0 striping with 2 to 4 in the array. Will Turnkey allow me to do this without having manually SSHing in and configuring the array. Since my current servers are Raid 5, I wouldn't want to take a performance hit by moving to EC2.
My question, will a subscription to turnkey EC2 Lamp AMI do anything to reduce my manual processes above? I'm assuming you addressed the non-persistent data issue by having a startup script to fetch previously stored persistent configuration data with your autoEBS mount. As part of my turnkey subscription, if my instance goes down, do you offer value added monitoring and alerts? I would want to know if my websites were down. I also would want the ability to restart them without having to login to AWS.
Signing up for the beta, I didn't realize you charged a premium over standard EC2 prices. It's a turnoff for me. I generally am willing to pay for a really useful add-on service e.g. backup, and encourage you to pursue this path.
Originally, I was skeptical about the possibility of having to pay more to use TKL on the cloud. After having access to the Hub, I don't see anything wrong with it. Consider you would pay $30 a month for usage fees. A 10% premium would mean you're only paying $33. And with the possibility of Micro Instances, the difference could be barely noticeable. For the simplicity the Hub provides, especially with TKLBAM, I would have no problem paying it. It is clear that you guys are putting some serious effort into the project and I think it would be a great way to help it grow.
I've been experimenting with tkl and have found it a good time saver. I'd like to use it to support various client needs for US based businesses. The problem I have is a lack of guaranteed support. Very small companies never ask about vendor support for software, but every other company (especially experienced ones) always will. I can't use these appliances with many companies without the ability to buy technical support from the vendor. I sometimes cannot even buy hardware without a service contract as some businesses just want to have it - even if they will never use it. It allows for less stress and to them legitimizes the vendor.
The idea of mark-ups on top of variable costs drives small business owners crazy. They do, however, accept the premise of paying for a yearly technical support contract for two reasons:
1) They only have to pay one bill a year
2) This lets the owners feel better that their server instance can get vendor help when it has issues. After all - they rely on their business for income and they need to know their problems will get addressed from the vendor when needed.
These owners and decision makers do not understand the concept of open source other than free. Of course they want everything for free, but they want the assurance provided by a support contract as well. Have you considered raising revenue by offering some type of support contracts?
Meanwhile, in a strange coincidence, we were just doing the brainstorming an upcoming offering that includes bundled support though it's mostly aimed at ISVs and hosting providers that would be natural sponsors for the project, and could benefit from the support of the Core team to get them through the rough spots in implementing TurnKey based solutions.
Thanks to everyone who provided feedback over the past year. The poll is closed and in accordance with the winning option Amazon will soon begin charging TurnKey users on EC2 a modest 10% premium on hourly usage fees.
The change will take effect in about two weeks, which should be just in time for the new TurnKey Linux 11 release, based on Ubuntu 10.04 Lucid, the most recent version of Ubuntu with Long Term Support.
Currently this modest premium will only provide the project with a few hundred dollars each month. Not much, but enough to cover some costs.
With the next release we're hoping to see usage increase significantly so that this premium will eventually add up to something meaningful that can help support future development.
Many thanks to the hundreds who voted in the survey and participated in the discussion throughout the last year.
At the time of poll closing, the results were as follows:
For those of you who didn't follow the discussion, a few alternative ideas were introduced, including charging a fixed monthly fee instead of incremental hourly fees. We considered this, but ultimately decided that fixed pricing, though more financially lucrative for the project, would be a poor fit for the majority of our users. For example, is it reasonable to ask an individual that wants to run a quick 1 hour demo to support the project in the same proportion as a company running multiple instances 24x7?
To everyone who participated in the beta over the last year, thanks for trying out TurnKey Linux on Amazon EC2 and providing feedback!
The poll resulted in a roughly 11.8% surcharge, so you guys are implementing about a 15.25% discount on the community's own estimated opinion of value. That's awesome! I know everyone won't see it this way, but the numbers don't lie. :D
It made me think about it.It made me.Think about it.
Thats such a cool way of looking at it! You'll fit right in around here Jeff!
More information about text formats