Create app "packages" for 'managed' cloudrons

[micmc]

@scooke That's excellent examples of ways to use the already existing power of CR, and it shows that it's incredibly flexible, and that there are many ways to do things depending on the application you want to use it for.

When I say imagination is the limit. I totally mean it.

[micmc]

@girish so the idea of leaving this feature as optional to the initial owner/installer of the instance opens the possibility to either deliver full Cloudron to certain clients AND "managed" Cloudron, thus the idea in my title, to some other client types. all depending on one's business model and target market.

[girish]

@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 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.

I forked this to a topic of it's own, would be interesting to know if other's are interested.

[luckow]

To me, it sounds like ansible could be a solution. Define your "bundles" as a Cloudron-API/CLI-script and fire up the whole installation process. Maybe one day, you are able to buy a subscription upfront and add it to your ansible-playbook (the installation process).

The only problem I see is that you cannot limit the number of users on the Cloudron side. So you more or less have to choose the right VPS for up to 50 or up to 200 users.

[thetomester13]

Not sure about software for this exactly, but this could be replicated easily (after doing it once) via API calls and some scripts to run certain API calls in order?

[scooke]

Yunohost, for one, does allow an admin to see ALL the possible apps available for installation, BUT they categorize these apps by reliability and stability.

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. The Customer never really knows if you've overbooked the VPS or not, or if "better or stronger" options could be available - they only see what the SuperAdmin has packaged as choices.

So, the SuperAdmin would need a way to create a Package, and then assign specific App Store apps to each Package.

In fact, a similar process must already be in use for Cloudron, because only those apps that are "ready" are in the App Store (and even then some are labelled as Unstable)! So, can that be tweaked to let a SuperAdmin make visible only those apps being offered?

I'm babbling on now. Time for bed.

EDIT: I guess the same ability to tweak (using APIs?) could also make the SuperAdmin visible or not in the Admin's Dashboard User list; or hide it from the users in the User List.

[micmc]

@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.

[Benoit]

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

[micmc]

@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.

[micmc]

@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.

[scooke]

@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.

[robi]

would an integration with Directus be suitable for this? @marcusquinn ?

[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.

[robi]

@marcusquinn That wasn't the question.

[Benoit]

@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.

[nebulon]

@Benoit the package description is part of the app package. If you want to update some of those, we happily accept merge-requests in their git repos. You can find all of those at https://git.cloudron.io/cloudron

[micmc]

@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?

[micmc]

@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.

[Benoit]

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.

[micmc]

@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.