Create app "packages" for 'managed' cloudrons
-
@girish said in Create app "packages" for 'managed' cloudrons:
@micmc The idea to create bundles is interesting. Do you (or anyone) have experience with software we should integrate with that makes this possible ?
I was not referring to something that much elaborated as integrating another software or piece of code into Cloudron to accomplish this. On the other hand, depending on how you see the "packaging" idea from your side it's not excluded that something could exist. There are many ways to accomplish one thing in software.
I am not sure if we want to implement this system ourselves. It's best to integrate with something else that can create bundles, manage your customers, payments etc. And cloudron can integrate with it by exposing the necessary APIs.
Now this is where you should be a little more explicit with what you have in mind regarding this idea. Of course if we get onto the API transactions side, now something else could be imagined and elaborated I can see what you mean. And, yes maybe it could be through the use of another software.
Would a CRM be something you had in mind to accomplish that?
I was more referring for the moment to something in the like of creating kind of a custom installation providing access to only what's described in the package offer through a yml file for example. But after that, as @luckow brought up down below, there should be also a way to implement some sort of limitation as well.
For example:appstore: noaccess: - io.wekan.cloudronapp - io.cloudron.openvpn - etc. yesaccess: - org.wordpress.cloudronapp: {5} - com.nextcloud.cloudronapp: {1} - etc. {}
Sort of. Of course that means that all the apps in the package will not be installed. Rather they will only be available, or not, and limited.
As it was brought up as well, "Users" is something else, yep. And, well, afterthought that might not be that important after all in terms of packaging. Because if the amount of users is unlimited with any package, that should still somehow help to get the client to scale up its package with an increasing amount of users.
And yes, that would also means that any 'managed' Cloudron package would come with unlimited email accounts, an then yet another way to increase the need to scale its needs.
-
Hi,
it could be interesting to have the possibility to present the apps with our words in the app store and not in technical words. Some clients we have doesn't understand what the apps do before they have our point of view and explanations about it. we are trying to democratize the use of open source apps and for that we have to get out of technical jargon. It would be amazing et we could adapt the app store app description and hide to complicated apps for example. Sorry for my english, I hope to be understandable.
Benoit
-
@luckow said in Create app "packages" for 'managed' cloudrons:
To me, it sounds like
ansible
could be a solution.Absolutely! My initial idea was to maybe perform some custom script, a standard of course, that would be somehow triggered while you register the new instance from your cloudron.io account. However, Ansible could also be used to accomplish after the instance is installed and could also be used to upgrade the package for the clients from the provider/MSP's side through CLI. Before or after you'd performed the installation, that would be something yet to consider.
Maybe one day, you are able to buy a subscription upfront and add it to your ansible-playbook (the installation process).
Why not.
-
@scooke said in Create app "packages" for 'managed' cloudrons:
Could the same idea/process be adapted for a Superadmin to "categorize" Cloudron App Store apps, making only certain ones visible to the next level Admin. Come to think of it, a Reseller account on MXRoute allows the Superadmin to do exactly this - create a Package, name it, define it's parameters, and allow the Customer the option to choose from the prepared Packages.
Sort of. That resemble the analogy with WHM - Cpanel I use to explain the idea in my OP here.
-
@Benoit Less technical jargon is fine, but I've always appreciated that Cloudron doesn't obfuscate the name of the software being used. I think it is better that any level of user know that they are using APP_NAME, rather than a rebranded or just renamed software. As an example, I came across another project that does this - https://www.colibris-outilslibres.org/. I'm not sure why they renamed Sondage from Framadate to Sondage, YesWiki to Wiki, Jitsi to Visio (although this one is less "hidden" since it is clearly a Jitsi instance on the homepage), Mattermost to TChat, Peertube to Video, Polr to Colibris.Link, and Scrumblr to Post-It. I don't know why they do this; I would think that promoting the use of open source and self-hosted software would gain even more credence by using the well-known name of well-used software. Is it to give the impression "they" created this software? Wouldn't users feel more at ease knowing that the code is the same as what everyone else who openly and clearly uses APP_NAME? Are they trying to establish a market name? For me, looking back at my own journey, I feel I'd be surprised to find out that "TChat" is not their app but is in fact Mattermost, which I've heard about, as an example.
I think in another post where I brought this up ppl pointed out that the nature of the licences allows people to rename the software. I just hope this isn't part of whatever "Package" option that Cloudron develops.EDIT: I just checked out your company and am happy to see you've taken the Cloudron route and displayed exactly what the software is you are offering without renaming it. Cool.
-
would an integration with Directus be suitable for this? @marcusquinn ?
-
I loath per-user charges for anything - it is an artificially unnecessary restriction. Far better to charge for resources. I'd actively go out of my way to circumvent any per-user licensing restrictions, including promoting competitive alternatives without it.
-
@marcusquinn That wasn't the question.
-
@scooke i don't want to change the apps names. I don't want to hide logos, marks or apps websites. We want to show that open source apps are an alternative to the GAFAM apps. We want to promote open source apps. What i would like is to have the hand to edit app store apps description with more explicit words for non technical users. I don't know how it could be done on the app store and if it is possible but it would be a big + for us and our clients.
And the fact we can't translate the app store description adds some complication for our clients. -
@Benoit said in Create app "packages" for 'managed' cloudrons:
Hi,
it could be interesting to have the possibility to present the apps with our words in the app store and not in technical words. Some clients we have doesn't understand what the apps do before they have our point of view and explanations about it. we are trying to democratize the use of open source apps and for that we have to get out of technical jargon. It would be amazing et we could adapt the app store app description and hide to complicated apps for example. Sorry for my english, I hope to be understandable.
Benoit
Quite understandable for sure and I really get your point because providing more generic, or more wide publicly understandable, names for the app with meaning. Believe me I hear you because that would be of help for some of my target market.
And we're back to what I keep saying, some feature can be from fantastic for one and an horrible idea for another, because points lifted by @scooke here below are as quite good and legitimate too.
I'm part of both world, yeah the people side who are now forced somewhat to live with technology and learn to take advantage of it, and the techies world who develops, installs, integrates, manages, and maintains all this for the people.
One thing's for sure is Cloudron is built by and for the second "world" I talk about, and as such changing the name of the apps in the apps-store would be totally out of the question for me.
However, we could certainly find a way to satisfy needs of all.
What pops my mind quickly is there could be a chart presented to the client somewhere that could provide instant understanding of the app is or what it does, so the client can lookup from what he wants to do, and be presented with the available apps he can use for such specific task. For example, there's the Category list from the drop-down menu at the top of the app store, may be something that could be rethought?
-
@scooke said in Create app "packages" for 'managed' cloudrons:
Mattermost to TChat, Peertube to Video, Polr to Colibris.Link, and Scrumblr to Post-It. I don't know why they do this; I would think that promoting the use of open source and self-hosted software would gain even more credence by using the well-known name of well-used software.
All your points are good of course. Now, whatever is their reason to do so, at first look they're clearly reflecting the concern addressed by @Benoit because it all depends on your target market may I say it again.
Outside of Internet technologies world, among the people out there, very few who know the biiib about Mattermost, Jitsi, or even Nextcloud and it's a fact. So, when we think about it "packaging" could also help to address the problem for both world. And that all depends on HOW you present the "product" to your target market.
Example:
With package One you can easily publish a website without coding, communicate directly to all visitors though an instant chat device on your site, access all statistics you need to tweak your marketing, and create unlimited email boxes with IMAP, POP3, and SMTP.You get:
- list your
- apps
- for package one
- with REAL app name
Again, imagination is the limit.
-
It could be a manageable app store by the super admin of the cloudron. He could hide the default app store for non technical clients and choose what apps need to be accessible with a customization on the description of these apps. it could be an interface with toggle buttons to activate or deactivate some apps. And you can choose the text you want to show for each app activated. the process to install would be the same. Be careful for me in the back, it is the same app store but it is the front what is different and more compatible with newbies and non tech users.
it is a big improvement but it does not seem impossible to do for super @girish ;). Perhaps i don't see all the difficulties it could engage.
Anyway it could be a more comprehensible interface to help the onboarding of new users. -
@marcusquinn said in Create app "packages" for 'managed' cloudrons:
I loath per-user charges for anything - it is an artificially unnecessary restriction. Far better to charge for resources. I'd actively go out of my way to circumvent any per-user licensing restrictions, including promoting competitive alternatives without it.
It's NOT what we are discussing here and resources or scaling as been touched also part of the idea.
-
@Benoit said in Create app "packages" for 'managed' cloudrons:
It could be a manageable app store by the super admin of the cloudron. He could hide the default app store for non technical clients and choose what apps need to be accessible with a customization on the description of these apps. it could be an interface with toggle buttons to activate or deactivate some apps. And you can choose the text you want to show for each app activated. the process to install would be the same. Be careful for me in the back, it is the same app store but it is the front what is different and more compatible with newbies and non tech users.
Certainly, this is another way of seeing and doing things to accomplish this, and it's great ideas as well. That's the reason for such forum and how genius software are created. We have here a crowd of people with amazing backgrounds of all sorts and it's the main reason we've a rich community.
it is a big improvement but it does not seem impossible to do for super @girish ;). Perhaps i don't see all the difficulties it could engage.
Anyway it could be a more comprehensible interface to help the onboarding of new users.Ah, you're conscious all is possible with @girish right?
-
-