More on Whitelabelling Cloudron for providing managed Cloudron instances

[micmc]

As promised here here are more findings and suggestions that I propose for whitelabeling cloudron

I'm also including here the suggestions also brought up by @nothing that were also appreciated by @girish and fit well with some other suggestions I'd also proposed in some other threads (see references below)

Branding is too limited and the following are a few things I have noticed:

• Page Titles still contain Cloudron e.g. User account creation
• Emails sent to user with "Cloudron" in the subject, "powered by Cloudron" in footer
• In user's dashboard, hovering over fa-user icon user is prompted to "Login with Cloudron credentials"
• "Cloudron account" in a user's profile under App Passwords
• DKIM cloudron._domainkey prefix should be changed, not only for branding but other reasons (obscurity). Why needlessly announce an organization is using Cloudron?

Branding should extend to the above. and anything I have yet to see, especially in an Enterprise setting. It should reflect the name of the organization. Ultimately, the user is creating an account with the organization, and not with Cloudron.

Also, refer to features I proposed in a previous great discussion about Hiding superadmin to deliver 'managed' cloudron to clients.

So here's what I add, that I also came out for whitelabeling implementation of cloudron.

FOR THE ADMIN user (the not superadmin or superuser)

In SUPPORT should not have to 'verify' their email address with cloudron.io, then their should be implemented a field on a 'white label form' to fill, which will add the white label registrar's contact information or a mean to reach it instead of cloudron.io

In SUPPORT one should not see "You can also write directly to support@cloudron.io." again that could be either hidden or use a contact form to which WL registrar would add on the 'white label form to fill'

In SUPPORT ticket form should be sent to owner/superadmin of the white labeled CR instance - can be set or not through superadmin

In SUPPORT "remote support" feature should not be seen by admin but superadmin only, for WL version, because WL registrar would take care of the support of its clients. So, owner/superadmin would be the only one to use that to allow cloudron.io access to the server, if needed.

In SUPPORT superadmin should also be able to customise links to KB, Tutorial, and Forum, very likely through the 'white label form' to fill and submit to customize the cloudron instance as WL. So, again WL registrar can handle its own KB, its own Tutorials, and its own users' forum.

In EVENT LOG one should be able not see the superuser activities, if not superuser oneself (I guess it appears, I'm not sure)

In NETWORK at the moment logged in as admin I cannot see the Firewall function. Alright, while I can imagine why admin user cannot block IP addresses (reasons?), for WL version I would not see a problem to leave this feature at admin level, as well as superuser of course.

In USER DIRECTORY admin should not be able to see the superadmin role, in role's dropdown choices, when adding a new user.

In APPS admin should not be able to see superadmin in Access Control users' dropdown choices

Creating a WHITELABEL instance should be as easy as using a special code when one registers a new license from within one's cloudron.io account's UI. And that instance should then be added to the WL registrar (cloudron WL provider using its WL code) pool of WL instances.

Now, for the all the documentation links all over inside the box, in oder to keep the WL offer full and constant, I believe the easiest solution that would also be fine for all users of the cloudron box, WL or not, is to put all the docs on a new domain name dedicated just for that does not refer nor link back to the developer's website. The way it is done for now is not useful and confusing for any end users already.

Several cloudron owner use their instance to serve clients of their own already, so anytime an end user stumbles on a meaning to reach cloudron.io in any way, that is where the confusion starts occuring, because cloudron.io might not be their service provider in many cases. Moreover, that is also a protection for the client finder that its end user will not eventually bypass the original provider by going straight cr.io even if it's only inadvertently. Or even to keep competitors away from the 'secret software' they use as a provider loll

There's no need to hide or replace the name of the box, cloudron, for the domain. As long as it's not directly linking users back to the develpers' website. That should be very easy and quick to implement using search and replace technique in the source code to change all the documentation links at once. Domain name should not be very hard to find or decide on, I'm sure something like cloudrondocs.something should be very easy to find.

And, also to make it more specific and easier to distinguish I'd suggest that maybe the term 'SUPERUSER' should be replaced to use OWNERADMIN instead.

More discussion revolving around the same views for brandind and whilabeling

Create app "packages" for 'managed' cloudrons
Branding Limitation

Any comments and or suggestions are of course very welcomed.

[marcusquinn]

Or just have a "partner programme", where that partner is referred leads for any local manage service provider needs. Cloudron does framework, partner does implementation. Clear, with credit or responsibility where it is due.

[micmc]

@marcusquinn said in More on Whitelabelling Cloudron for providing managed Cloudron instances:

Or just have a "partner programme", where that partner is referred leads for any local manage service provider needs. Cloudron does framework, partner does implementation. Clear, with credit or responsibility where it is due.

As far as I can understand you here, a "partner program" as you suggest is totally something else in many ways. It also focuses on a totally different business model with much less flexibility and possibilities than one have with White Label version.

For a start, I'm not suggesting that cloudron changes its actual business model. So, it would change nothing to how it works and how you can do things right now in any way, with cloudron.

It much depends on the goal one wants to reach with the technology, but nothing prevents the owner to create a partner program as well if some are interested in such thing. Though there are several different implications for the developers too, in both models.

The main reason for a white label model is that one can develop and deploy many branded concepts with the use of the exact same technology. And as such, what's interesting for cloudron developers is that it allows for them to get a revenue increase, without the much increase in support and related resources that would require the same revenue increase, but with a partner program for example.

Another, major difference is about the end user, the client. In the case of a "partner program" you deploy marketing and sales as the clients finder, and then you pass them to cloudron devs. With WL model you find clients for your brand and concept from the cost of the marketing you deploy but the clients are yours. You get in your own program, even white labeler cans created their own partner program, you nurture them, support them, teach them support them, and upsell them to more related products and services if you wish. In other words you run your own show.

[marcusquinn]

@micmc 20 years in business tells me that would generate more costs than benefits for all concerned. I guess that there are the odd white-label products out there, but I just can't think of any notable, whereas brands with partner programs is a well-worn understanding and expectations.

I personally wouldn't invest my own time or money, or recommend anyone I cared about to pursue a business based on relabelled products, far too vulnerable, accrues duplications of effort, and is the anti-thesis to open.

Maybe you've different experience, but, this is one of those rare well-intended suggestions I'd just down-vote if that were an option.

[micmc]

@marcusquinn 32 years in business tells me the whole contrary mate

Among these years are 22 online developing, providing and integrating Internet web, communication and marketing technologies.

As I explained, the functions to allow whitelabeling cloudron I propose would not touch how you, or anyone else, do business right now with Cloudron technology and devs, and not even how you use it at your own convenience. No one will force you to use the white label version, promise.

So, in such regards I wonder why you insist in hijacking the thread with irrelevant comments since you've already stated your opinion for creating a partner program, and I'm perfectly fine with it and respect it, and, obviously WL is not something for you if you don't see the potential. And it's because you not have a clue of what you personally would do with it. Obviously, you've your ideas and fortunately some others have other ideas to make this model profitable.

I know of several HUGE SaaS web services that have white label version of their software and a few friends veterans in online marketing running them. So, you're exactly right, one business experience does not necessarily reflects the whole industry.

I've not asked for business advice here nor asked for votes. And moreover I have not even exposed my business ideas yet, but if that idea disturbs you that much for some reasons, check on some other threads man lol why not start a thread, yeah start a thread for proposing your partner program idea, which is cool also.

I've run both in my career white label and partners program, and even affiliates programs and have make huge mass sales as in the 5-10 figures in a few days, through powerful well crafted marketing campaigns. I think I know what I'm talking about and know very well what I'm doing. Take care.

[plusone-nick]

EDIT To keep the theme going: "10 years in business tells me...+1" lol

@micmc I do agree on adding some/more features geared toward managed Cloudron providers (although I am totally biased here aka on your side lol) but the issue would be effort as @marcusquinn suggests.

The main factors I see between the suggested features are

• Branding
• Administration /support
• Admin vs Superadmin

The main problem I see is for a fully fledged "White label" platform/user experience one would have to refactor every app to have a similar theme, OR make custom UI's and integrate with every single app...
There is not much of a point of "hiding" Cloudron as a platform but then leaving the branding for RocketChat, NextCloud and the rest of the apps...I get and agree with your end game but as you mentioned users can try and go to the respective project sites/docs or team for support given they know what's "behind the Curtin"
Yes having the "platform" not branded to Cloudron and instead be "XYZ" MSP or the clients company is a good thing but IMO its the "Last" important thing

Pretty much all of what you are suggesting especially the text/link branding is valuable but the issue is more about priority/capacity of the core devs

Taking the slow and steady route and eventually getting to the full feature set seems to be the more logical route given the size of the Cloudron team and the other tasks at hand. Point is there has to be a middle ground for everyone to get "a version" of Cloudron that they want/need, in time...My suggestion would be for us to prioritize the features and advocate for one at a time

Last minute thought before publishing: maybe Cloudron team does not have to change how the admin profile works but could add another profile like "OWNER" for example where the text*/links are more ideal from* an MSP standpoint

Regardless, I am very interested and vested in a similar outcome so if you'd like to talk more here or directly shoot me a message , always down to converse with likeminded ppl

+1

[micmc]

@plusone-nick You see, 10 years, 20 years or 32, does not really matter with ideas, right.
That's because ideas, like inventions, are born out of a necessity to create a solution, and commercially speaking for the best chances of success that solution must be a win-win one. That is, profitable for the developers and for the end users (providers/clients).

And I appreciate all comments, this is how I believe we can tend to perfection. On the other hand one must be realistic at all points, especially when there's no real motive to be against something that will not affect the 'opposition' lol My experience tells that in 99% of the cases it's based on misunderstanding. And I can verily live with that.

Hopefully, one has also checked out all the threads I quote and include in my OP. And there are even more but I did not want to overload this one. Because what I'm talking about here is not a surprise and I'm not 'new' here.

There are pieces of suggestions and discussions in this regard all over the place in the forum. And for a few years now, I've engaged in much discussions with @girish and devs through the old rocketchat channel and through email about the possibilities to market the technology. At some point we agreed to put more about the idea of WL in the forum because the potential is huge for anyone who would have a use (a marketing idea and plan) to market cloudron licenses through that mean. What's the real power behind 'MikeroFoft'? The software, not at all right, then it's the power of marketing.

No one, among actual users and adopter, will even be aware it exist a WL version, unless they dig more or pay very close attention, or ask for it. All my ideas and suggestions have always been thought and proposed in that very direction. I've never discussed nor proposed, let alone pushed, the awesome cloudron devs folks to change anything of the model they chose to run and are running.

Not at all. It's the contrary it's all thought so they can be able to provide such WL version (a little bit inspired from the old 'hosting provider' version they had at some point, but more integrated with their new registration UI) as a totally parallel system that would not interfere with what they are actually doing, and at the lowest possible development needs. There will still have a need for integration development from the WL registrar side into their chosen marketing model.

It's always oriented to be a win-win situation, which consist of an important increase of revenue for the devs for the same product, but at the lowest development cost as possible, and without the hassle of equivalent increase in needs for support and resources. And, even, without the risk of getting quickly overwhelmed with a sudden increase in the number of new users and demands that they might not be able to get over for a certain while, and so then, yes, that would affect the existing support pace other users are getting in the forum right now, and also losing sales.

You've pointed the right factors in question and it's all already covered.

There's NO problem, it's all already thought and feasible solutions.

• Branding
  From within its cloudron io user account if one is a WL registrar, when it wants to register a new cloudron instance it's like anyone else, its going have to enter a provided special key if it wants to brand it. By filling a special form this instance will be branded as required, and then can be delivered to its customer.
• Admin and support
  as explained in the OP one enter its support means and credentials in the form for customizing the relevant places in this cloudron instance.
• Admin vs superamdin (or superuser) it's also well covered in the OP and some threads I quoted, it's already being implemented in many ways.
• There's no point to try to somehow 'brand' the apps, These are FOSS apps and should stay as is. It's never been in question and never will be. Though, just as anyone can right now, one can choose to brand an FOSS app to provide the service to end users.
• Basically, it's all about the branding capacity of a cloudron license/install. So there's no concern about "priority/capacity of the core devs" at all.
• From what I know and my side of things, and according to the feature I propose, there's nothing complicated to the point of going a "slow and steady route and eventually getting to the full feature set". It's quite simple in itself for a simple implementation, without much risk if any, for a start.
• Again, it's mainly a branding matter and maybe it's the use of the term 'version' that creates a certain misunderstanding here, and near panic at some points lolll (I'm kidding) nothing will change for anyone. Only, if you decide to register for a branded version of cloudron then you will need to use your WL branding special key at registration in your account. That's it.
• There's no need to add another profile like owner, this is already covered up as well. Unless I miss your point what I propose is pretty good for MSPs as it's also the idea that MSPs can have a branded backend if they will.

Thanks for the +1 and for allowing me to clarify things a little more mate.