A Mandate to Be Cheap
-
@DustinB3403 said in A Mandate to Be Cheap:
@Dashrender said in A Mandate to Be Cheap:
@DustinB3403 said in A Mandate to Be Cheap:
@Dashrender said in A Mandate to Be Cheap:
@coliver said in A Mandate to Be Cheap:
@Dashrender said in A Mandate to Be Cheap:
@scottalanmiller said in A Mandate to Be Cheap:
@DustinB3403 said in A Mandate to Be Cheap:
The term cheap to me (and I think others) means it needs to perform to the level that we can still run production (or whatever the use case is) and save more money than what we may have been proposed before.
That's an undefinable definition. Cheap but not the cheapest, good but not the best for us. So not the best option for the business, but not recklessly cheap. How do you make decisions around that? How do you decide what is "cheap enough" while being "not so bad" but not just choosing "what is best for the financial interest of the business?"
I'm seriously, without a clear definition but also without the goal of doing what is right for the business... what's the motivator for this? What makes something the lesser choice, but good enough?
Isn't part of being the best solution also having the lowest cost while still getting all of the needed items from that solution?
Right, but cheap denotes that you are making sacrifices that would stop you from getting the best solution for you business. At least to me it does.
So can it be cheaper and still solve the problem and not be the best?
Xen Orchestra from the sources is as cheap as it gets (because of the functionality of it). Meaning the XO Updater script, the capability to install it in a matter of minutes.
The fact that XO by it's self is disposable, and recreated in minutes.
Not that I don't love @olivier for the work he's created, but the source option is literally the best choice for this business.
is it? Could you spend the time you spend updating XO doing other things that are more valuable to the company? Maybe? Maybe not?
./xo-update.shIt's a 15 second command at most, that installs the most current updates. How much value can be squeezed out of 15 seconds?
It can even be scheduled via cron...
I feel I will "laugh" a bit when we'll migrate some data via the updater and a special script because we changed the data structure for a lot of technical reasons. Remember that doing that don't mean you have control. It could also break your install anytime due to npm.
A lot of customers don't want to take that risk. XOA price is not the software, it's the support.
-
@olivier Hey that's why we have a beta system.
-
@DustinB3403 said in A Mandate to Be Cheap:
@olivier Hey that's why we have a beta system.
So you have to maintain a beta system, find out when it breaks, migrate the data (if it happens) and check how to do that, and then update the production.
That's OK, but it starts to cost time...
-
@olivier said in A Mandate to Be Cheap:
@DustinB3403 said in A Mandate to Be Cheap:
@Dashrender said in A Mandate to Be Cheap:
@DustinB3403 said in A Mandate to Be Cheap:
@Dashrender said in A Mandate to Be Cheap:
@coliver said in A Mandate to Be Cheap:
@Dashrender said in A Mandate to Be Cheap:
@scottalanmiller said in A Mandate to Be Cheap:
@DustinB3403 said in A Mandate to Be Cheap:
The term cheap to me (and I think others) means it needs to perform to the level that we can still run production (or whatever the use case is) and save more money than what we may have been proposed before.
That's an undefinable definition. Cheap but not the cheapest, good but not the best for us. So not the best option for the business, but not recklessly cheap. How do you make decisions around that? How do you decide what is "cheap enough" while being "not so bad" but not just choosing "what is best for the financial interest of the business?"
I'm seriously, without a clear definition but also without the goal of doing what is right for the business... what's the motivator for this? What makes something the lesser choice, but good enough?
Isn't part of being the best solution also having the lowest cost while still getting all of the needed items from that solution?
Right, but cheap denotes that you are making sacrifices that would stop you from getting the best solution for you business. At least to me it does.
So can it be cheaper and still solve the problem and not be the best?
Xen Orchestra from the sources is as cheap as it gets (because of the functionality of it). Meaning the XO Updater script, the capability to install it in a matter of minutes.
The fact that XO by it's self is disposable, and recreated in minutes.
Not that I don't love @olivier for the work he's created, but the source option is literally the best choice for this business.
is it? Could you spend the time you spend updating XO doing other things that are more valuable to the company? Maybe? Maybe not?
./xo-update.shIt's a 15 second command at most, that installs the most current updates. How much value can be squeezed out of 15 seconds?
It can even be scheduled via cron...
I feel I will "laugh" a bit when we'll migrate some data via the updater and a special script because we changed the data structure for a lot of technical reasons. Remember that doing that don't mean you have control. It could also break your install anytime due to npm.
A lot of customers don't want to take that risk. XOA price is not the software, it's the support.
Absolutely, it's all about support. And it makes sense for most "greater than one" man shops. Or for those that are overworked or lack the skills to self maintain.
-
@scottalanmiller said in A Mandate to Be Cheap:
@olivier said in A Mandate to Be Cheap:
@DustinB3403 said in A Mandate to Be Cheap:
@Dashrender said in A Mandate to Be Cheap:
@DustinB3403 said in A Mandate to Be Cheap:
@Dashrender said in A Mandate to Be Cheap:
@coliver said in A Mandate to Be Cheap:
@Dashrender said in A Mandate to Be Cheap:
@scottalanmiller said in A Mandate to Be Cheap:
@DustinB3403 said in A Mandate to Be Cheap:
The term cheap to me (and I think others) means it needs to perform to the level that we can still run production (or whatever the use case is) and save more money than what we may have been proposed before.
That's an undefinable definition. Cheap but not the cheapest, good but not the best for us. So not the best option for the business, but not recklessly cheap. How do you make decisions around that? How do you decide what is "cheap enough" while being "not so bad" but not just choosing "what is best for the financial interest of the business?"
I'm seriously, without a clear definition but also without the goal of doing what is right for the business... what's the motivator for this? What makes something the lesser choice, but good enough?
Isn't part of being the best solution also having the lowest cost while still getting all of the needed items from that solution?
Right, but cheap denotes that you are making sacrifices that would stop you from getting the best solution for you business. At least to me it does.
So can it be cheaper and still solve the problem and not be the best?
Xen Orchestra from the sources is as cheap as it gets (because of the functionality of it). Meaning the XO Updater script, the capability to install it in a matter of minutes.
The fact that XO by it's self is disposable, and recreated in minutes.
Not that I don't love @olivier for the work he's created, but the source option is literally the best choice for this business.
is it? Could you spend the time you spend updating XO doing other things that are more valuable to the company? Maybe? Maybe not?
./xo-update.shIt's a 15 second command at most, that installs the most current updates. How much value can be squeezed out of 15 seconds?
It can even be scheduled via cron...
I feel I will "laugh" a bit when we'll migrate some data via the updater and a special script because we changed the data structure for a lot of technical reasons. Remember that doing that don't mean you have control. It could also break your install anytime due to npm.
A lot of customers don't want to take that risk. XOA price is not the software, it's the support.
Absolutely, it's all about support. And it makes sense for most "greater than one" man shops. Or for those that are overworked or lack the skills to self maintain.
Exactly!
edit: "overworked" is not the only reason. Responsibilities are another. A lot of companies won't buy a software if there is no one behind.
-
Extra note: if a one man shop is using XO to make a living, that's business critical. And if you can't afford pro support for your core business, that's a risk.
-
@olivier said in A Mandate to Be Cheap:
@scottalanmiller said in A Mandate to Be Cheap:
@olivier said in A Mandate to Be Cheap:
@DustinB3403 said in A Mandate to Be Cheap:
@Dashrender said in A Mandate to Be Cheap:
@DustinB3403 said in A Mandate to Be Cheap:
@Dashrender said in A Mandate to Be Cheap:
@coliver said in A Mandate to Be Cheap:
@Dashrender said in A Mandate to Be Cheap:
@scottalanmiller said in A Mandate to Be Cheap:
@DustinB3403 said in A Mandate to Be Cheap:
The term cheap to me (and I think others) means it needs to perform to the level that we can still run production (or whatever the use case is) and save more money than what we may have been proposed before.
That's an undefinable definition. Cheap but not the cheapest, good but not the best for us. So not the best option for the business, but not recklessly cheap. How do you make decisions around that? How do you decide what is "cheap enough" while being "not so bad" but not just choosing "what is best for the financial interest of the business?"
I'm seriously, without a clear definition but also without the goal of doing what is right for the business... what's the motivator for this? What makes something the lesser choice, but good enough?
Isn't part of being the best solution also having the lowest cost while still getting all of the needed items from that solution?
Right, but cheap denotes that you are making sacrifices that would stop you from getting the best solution for you business. At least to me it does.
So can it be cheaper and still solve the problem and not be the best?
Xen Orchestra from the sources is as cheap as it gets (because of the functionality of it). Meaning the XO Updater script, the capability to install it in a matter of minutes.
The fact that XO by it's self is disposable, and recreated in minutes.
Not that I don't love @olivier for the work he's created, but the source option is literally the best choice for this business.
is it? Could you spend the time you spend updating XO doing other things that are more valuable to the company? Maybe? Maybe not?
./xo-update.shIt's a 15 second command at most, that installs the most current updates. How much value can be squeezed out of 15 seconds?
It can even be scheduled via cron...
I feel I will "laugh" a bit when we'll migrate some data via the updater and a special script because we changed the data structure for a lot of technical reasons. Remember that doing that don't mean you have control. It could also break your install anytime due to npm.
A lot of customers don't want to take that risk. XOA price is not the software, it's the support.
Absolutely, it's all about support. And it makes sense for most "greater than one" man shops. Or for those that are overworked or lack the skills to self maintain.
Exactly!
edit: "overworked" is not the only reason. Responsibilities are another. A lot of companies won't buy a software if there is no one behind.
Not in one man shops, though. The logic that they need support for their software normally carries over to IT and a single man can't reasonably support the internal IT in the same manner that they would want. So the two really don't go together.
-
-
@scottalanmiller said in A Mandate to Be Cheap:
@olivier said in A Mandate to Be Cheap:
@scottalanmiller said in A Mandate to Be Cheap:
@olivier said in A Mandate to Be Cheap:
@DustinB3403 said in A Mandate to Be Cheap:
@Dashrender said in A Mandate to Be Cheap:
@DustinB3403 said in A Mandate to Be Cheap:
@Dashrender said in A Mandate to Be Cheap:
@coliver said in A Mandate to Be Cheap:
@Dashrender said in A Mandate to Be Cheap:
@scottalanmiller said in A Mandate to Be Cheap:
@DustinB3403 said in A Mandate to Be Cheap:
The term cheap to me (and I think others) means it needs to perform to the level that we can still run production (or whatever the use case is) and save more money than what we may have been proposed before.
That's an undefinable definition. Cheap but not the cheapest, good but not the best for us. So not the best option for the business, but not recklessly cheap. How do you make decisions around that? How do you decide what is "cheap enough" while being "not so bad" but not just choosing "what is best for the financial interest of the business?"
I'm seriously, without a clear definition but also without the goal of doing what is right for the business... what's the motivator for this? What makes something the lesser choice, but good enough?
Isn't part of being the best solution also having the lowest cost while still getting all of the needed items from that solution?
Right, but cheap denotes that you are making sacrifices that would stop you from getting the best solution for you business. At least to me it does.
So can it be cheaper and still solve the problem and not be the best?
Xen Orchestra from the sources is as cheap as it gets (because of the functionality of it). Meaning the XO Updater script, the capability to install it in a matter of minutes.
The fact that XO by it's self is disposable, and recreated in minutes.
Not that I don't love @olivier for the work he's created, but the source option is literally the best choice for this business.
is it? Could you spend the time you spend updating XO doing other things that are more valuable to the company? Maybe? Maybe not?
./xo-update.shIt's a 15 second command at most, that installs the most current updates. How much value can be squeezed out of 15 seconds?
It can even be scheduled via cron...
I feel I will "laugh" a bit when we'll migrate some data via the updater and a special script because we changed the data structure for a lot of technical reasons. Remember that doing that don't mean you have control. It could also break your install anytime due to npm.
A lot of customers don't want to take that risk. XOA price is not the software, it's the support.
Absolutely, it's all about support. And it makes sense for most "greater than one" man shops. Or for those that are overworked or lack the skills to self maintain.
Exactly!
edit: "overworked" is not the only reason. Responsibilities are another. A lot of companies won't buy a software if there is no one behind.
Not in one man shops, though. The logic that they need support for their software normally carries over to IT and a single man can't reasonably support the internal IT in the same manner that they would want. So the two really don't go together.
XOA isn't really targeting directly "one man shops", except if it's a core business (ie selling the tool to people or rely on it's working to not go out of business if there is a problem)
-
A one man shop, in case of an emergency, doesn't have the resources to even know who to contact for support when things break because the one person that knows everything is gone when a disaster strikes (often.)
-
@scottalanmiller said in A Mandate to Be Cheap:
A one man shop, in case of an emergency, doesn't have the resources to even know who to contact for support when things break because the one person that knows everything is gone when a disaster strikes (often.)
A one man shop isn't a shop with there is one people inside it? Or you mean "one IT guy shop"?
-
-
@olivier said in A Mandate to Be Cheap:
@scottalanmiller said in A Mandate to Be Cheap:
A one man shop, in case of an emergency, doesn't have the resources to even know who to contact for support when things break because the one person that knows everything is gone when a disaster strikes (often.)
A one man shop isn't a shop with there is one people inside it? Or you mean "one IT guy shop"?
One IT guy... single point of support, single point of failure
-
Okay so it could be companies from which size roughly?
-
Might I suggest a new thread.
We are venturing into an area that @scottalanmiller and I were talking about at MangoLassi Con - i think it deserves it's own topic.
it can be either specifically about XOA and pricing or more generic if @olivier doesn't want to be that specific on a thread.
-
I don't care
-
@olivier said in A Mandate to Be Cheap:
Okay so it could be companies from which size roughly?
Well, it's not about size. It's about how they view IT and their business. A one man shop isn't enough for a critical organization. Even the smallest company might take themselves seriously have have more than one IT guy. This is why we often say that MSPs / ITSPs are the only way for the SMB market to have IT. Having internal staff when you have so little need for it is crazy. Too much money, too little value.
http://www.smbitjournal.com/2013/02/the-smallest-it-department/
-
@scottalanmiller So this kind of shop aren't doing IT in their core business. So why not externalize it? Far cheaper than having a dedicated IT guy.
I mean, roughly the idea is:
- externalize everything that's not your core business
- internalize everything that's your core business
Here in France, there is very few SMB's with one IT guy. On what I see on the field, those in these case are using service providers, that's all.
I wonder, is it a common case elsewhere to have a dedicated IT guy for a small company selling shoes?
-
@olivier said in A Mandate to Be Cheap:
@scottalanmiller So this kind of shop aren't doing IT in their core business. So why not externalize it? Far cheaper than having a dedicated IT guy.
No one knows what crazy logic these companies have. But I've been preaching that any shop under three full time IT people is too small to even discuss having internal staff for many years.
-
@olivier said in A Mandate to Be Cheap:
I wonder, is it a common case elsewhere to have a dedicated IT guy for a small company selling shoes?
Yes, nearly always you'd find that. Every business either has their own IT or nothing at all and things don't work and are totally insecure and broken. MSPs are everywhere... but make up far, far less than 50% of the market. Internal IT rules because businesses are not smart, are taught to fear the concept of external services and because business skills are not taught here.
