We'd like to be able to hire a few people to join the team and work full-time on simplifying deployment of open source software. That means figuring out how to fund it since even people working on open source software still need to make a living somehow...
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.
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.
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?
Multiple pricing options are a bit confusing and might add unnecessary complexity. Choice isn't always a good thing. Besides, I think it makes sense in principle to price cloud deployment in proportion to usage. If you're a heavy user running a dozen instances full time it's reasonable that you would support the project more than the casual user who uses an instance for testing a couple of days a month.
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.
We're moving to a global subscription code to improve usability. Instead of having to subscribe to each appliance AMI separately you'll subscribe once to the library and be able to access any AMI.
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.
The question here isn't whether to start charging for downloads or a "premium" version. You can download TurnKey appliances and use them freely without paying anything.
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.
To the best of my knowledge EC2 users have always been billed for bandwidth between their instances and the outside world. This is part of Amazon's pay-as-you-go cloud model. If you have a lot of network traffic that can get expensive but by paying for the bandwidth's actual costs you know you're not getting an a service who's network bandwidth has been oversold and may perform poorly. Your provider has to pay for bandwidth in proportion to usage just like everybody else. I think the only significant exception is if you are a behemoth like Google and having peering agreements with the major network carriers and bandwidth still costs them indirectly by the cost to maintain their own massive network infrastructure.
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.
My first question is why tie the cost to EC2 instance costs?
AWS has a lot of variation in pricing EC2 use
Spot Pricing Instances
Reserved Instances
On Demand Instances
then there are various costs for different sizes of compute resources
Small Instance 32 bit
Med Instance 32 bit
Large Instance 64-bit
Extra Large Instance 64 bit
High-Memory Double Extra Large Instance 64-bit platform
High-Memory Quadruple Extra Large Instance 64-bit platform
High-CPU Medium Instance 32-bit platform
High-CPU Extra Large Instance 64 bit
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".
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.
Brian, you raise some good points but remember that Amazon limits us to what is supported by the DevPay program. A few of the ideas that have been raised by those who have commented here don't take those limitations into account.
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>
I like the idea of offering premium services (e.g., automated backup/restore, cloud management) that leverage the appliances and in fact we're going to start exploring that soon with the upcoming TurnKey Hub...
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?
There's a fixed program you can use for this sort of thing (DevPay) and you have to play by their rules if you want to play at all. It may get more flexible in the future but currently it's pretty rigid in what it allows.
Somnath Deb (not verified) - Sat, 2010/05/08 - 16:40.
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.
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.
Comments
More feedback from those who voted for 0%
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!
0%
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.
Thoughts on community funded development models
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.
Premium for EC2
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?
Simplicity in pricing + pricing in proportion to usage
Simple pricing
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.
Monthly fees not compatible with global subscription code
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.
when i start use any project for profit, i donate.
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.
Funding open source as an efficient way to pool resources
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.
variable expense creates budgeting issues
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.
Fixed monthly is better
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.
http://UnmeteredVPS.net/tkl
Try our TurnKey Linux appliance hosting FREE!
EC2 have always charged for bandwidth
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.
Need flexibility to use open source for free and donate later
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.
You can always download the ISOs and VM images for free
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.
http://UnmeteredVPS.net/tkl
Try our TurnKey Linux appliance hosting FREE!
Based on EC2 pricing - ? which small or xlarge?
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".
thanks
Same as Amazon
If you look at Amazon's EC2 pricing page:
http://aws.amazon.com/ec2/#pricing
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.
http://UnmeteredVPS.net/tkl
Try our TurnKey Linux appliance hosting FREE!
DevPay limits what you can do
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.
What about people with their own cloud?
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.
My Thoughts on Pricing
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.
My thoughts on pricing
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.
This week's change in pricing/support model for JumpBox & AWS EC
jumpbox.com/pricing
Just fyi...
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>
brian
Something like that
My two cents
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?
Amazon doesn't work like that
Feedback on pricing for custom EC2 images
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.
Somnath
What does a LAMP subscription provide?
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.
Thanks,
Larry
Post new comment