Changing some verbiage in XOCE
-
Back on the side of it's free and vates can do pretty much whatever they want with it, is still true. But while I agree that they are allowed to put banners in, to address source build users from going to them directly and expecting paid support, I in general think that it's a dick move in general.
As a business vates should step back from those user request and push the user back to the script dev for support first. Unless of course they are following the documentation on how to install from source without a script.
Which the script on my GH account, is literally following their process to a T, and post install makes changes.
-
For the XO team it's easy to think that it is their product and they have rights when all open source products stands on the shoulders of others. They would not have any product and not even an OS to put it it wasn't for others time and effort.
IMHO open source products should not have any information about support or no support. It's not in Mozilla Firefox, it's not in Apache OpenOffice, it's not in Oracle Virtualbox just to name a few. To write "no support" or at your own risk is just to increase sales, nothing else.
-
@Pete-S said in Changing some verbiage in XOCE:
To write "no support" or at your own risk is just to increase sales, nothing else.
That's exactly my thought on this as well, and is why I'm considering making these changes post install to more friendly verbiage.
I get their stance "support costs a ton of money", and there is no money to be made by supporting the "source build".
But it's still a dick move to keep adding these types of warnings rather than just not offering support for those source installations, right?
-
@DustinB3403 said in Changing some verbiage in XOCE:
@Pete-S said in Changing some verbiage in XOCE:
To write "no support" or at your own risk is just to increase sales, nothing else.
That's exactly my thought on this as well, and is why I'm considering making these changes post install to more friendly verbiage.
I get their stance "support costs a ton of money", and there is no money to be made by supporting the "source build".
But it's still a dick move to keep adding these types of warnings rather than just not offering support for those source installations, right?
Yes, it's a dick move.
-
BTW, do you change the name of it from Xen Orchestra to Xen Orchestra Community Edition?
It makes sense to be able to keep them apart.
-
@Pete-S said in Changing some verbiage in XOCE:
BTW, do you change the name of it from Xen Orchestra to Xen Orchestra Community Edition?
It makes sense to be able to keep them apart.
No, the name XOCE is just a simple way to help indentify people who've used my GH repo to install. It's nothing official as the official names from vatesfr is XO and XOA.
XO being any installation from source (with a script or by hand). And XOA being the paid support version
-
And as much as I hate to consider it, but it seems almost critical to run something along the lines of RH and CentOS/Fedora.
Which is a bit weird to have to consider doing, since the "build from source" solution and the XOA solutions aren't in any way different (technically) besides from the support channels to use.
-
@DustinB3403 said in Changing some verbiage in XOCE:
@Pete-S said in Changing some verbiage in XOCE:
BTW, do you change the name of it from Xen Orchestra to Xen Orchestra Community Edition?
It makes sense to be able to keep them apart.
No, the name XOCE is just a simple way to help indentify people who've used my GH repo to install. It's nothing official as the official names from vatesfr is XO and XOA.
XO being any installation from source (with a script or by hand). And XOA being the paid support version
But with the recent additions, and my redactions post install, it may become an official name for the installation script going forward.
I don't honestly know how to think about it.
-
And technically speaking there is nothing that would be "community" like CentOS or Fedora. As I'm not programming things that they are keeping closed source.
But in fact am just removing things that are annoying to see, and considering making the verbiage within the installation (once installed) more user friendly.
-
Also worth noting, that the scripts on my GH page, aren't forks of XO, but are just automating the installation process. It's why these types of changes have to occur once the install is "done".
-
@Pete-S said in Changing some verbiage in XOCE:
To write "no support" or at your own risk is just to increase sales, nothing else.
Definitely, it's cheesy and misleading. No support from them, perhaps, but no support at all is pretty misleading. It's pandering.
-
@Pete-S said in Changing some verbiage in XOCE:
BTW, do you change the name of it from Xen Orchestra to Xen Orchestra Community Edition?
It makes sense to be able to keep them apart.
Only makes sense to do that if there is different code.
-
@scottalanmiller said in Changing some verbiage in XOCE:
Only makes sense to do that if there is different code.
So technically, there is different code, but only once the source installation is completed and the edits are made to their source files.
IE this > https://github.com/Jarli01/xenorchestra_installer/pull/45
That is a change to the code, but post install. Obviously this install script isn't a fork of the XO repo so I don't think it should qualify as a separate product per-say.
-
Is customizing something post install actually a new product? I honestly need some feedback on this and hopefully something meaningful would come from this conversation.
I don't want to split hairs here, but it has seemed from the beginning that this script in particular has raised hairs on the back of @olivier.
But that is the beauty of open source, no? Anyone can do what they want with it.
If you are having such a hard time because you have more people building from source than purchasing professional support, is it fair to spam that user base with annoying things like "this version has no support"?
-
@DustinB3403 Technically, you haven't installed it when you modify the source. You've copied the source to the local machine.
-
@Danp said in Changing some verbiage in XOCE:
@DustinB3403 Technically, you haven't installed it when you modify the source. You've copied the source to the local machine.
If this is correct, then you basically are forking it.
-
Configuring is not forking. It's still the original being installed. And don't use any term like "install from source". The source and the install are the same thing, installing from source means something very specific that last I knew, cannot be applied here. There is no source and binary. All of XO is source at all times.
-
My reply is in response to a post on my GH account regarding the same topic.
While I agree that changing some of the verbiage here via this install script would at least be a means of evidence, the goal isn't to prove or disprove what the vatesfr team is stating but to hopefully get people to understand where and what level of support is had with "building from source."
It's a bit of a battle, because and I feel very strongly that at least Olivier doesn't want to support at all the source installation method and as such should simply instruct his team to not offer support if someone doesn't have a contract with them.
So while making these changes makes sense from a community standpoint, the problem lies with the Vatesfr business and not the software or verbiage as it exists and is portrayed.
-
Which to that point, then means, maybe we should just submit a PR for changing the verbiage from "No Support" to something more communal and less off putting.
But even with those changes, I doubt that the underlying issue would get resolved without something more drastic, like changing the "Bug Tracker" link to point first to the individual's GH accounts who've create install scripts.
-
@DustinB3403 said in Changing some verbiage in XOCE:
But even with those changes, I doubt that the underlying issue would get resolved without something more drastic, like changing the "Bug Tracker" link to point first to the individual's GH accounts who've create install scripts.
Which, would be up to the script author and team to ensure that the content is updated to point to the correct location. As certainly the Vatesfr team has no way to submit that change short of submitting PRs to each of the most highly used scripts with those changes.
And those PRs could still be decline/ignored etc.
