Why not make Cloudron fully open source again?
-
@mehdi
Nope, Sec. 13 of the license does contain „selling“ a service, it speaks of „make the functionality of the Program (…) available to third parties“.
If you provide access to a MongoDB instance - e.g. you host an app that others can interact with - and that uses MongoDB, you’re in.And the definition of „Service Source Code“ - the one you have to publish - is extremely broad.
The same applies to Elastic / Kabana by the way, they switched to SSPL as well (they also use Elastic V2 license but that’s worse).
@necrevistonnezr said in Why not make Cloudron fully open source again?:
make the functionality of the Program (…) available to third parties
This means directly. When you host an app that uses MongoDB in the back-end, you are making the app itself available, not mongodb, so no, it does not apply.
CF this citation from Mongo's own FAQ about SSPL:
Does section 13 of the SSPL apply if I’m offering MongoDB as a service for internal-only use?
No. We do not consider providing MongoDB as a service internally or to subsidiary companies to be making it available to a third party.
Or also :
What will happen if someone in the community is currently building something on MongoDB Community Server?
There will be no impact to anyone in the community building an application using MongoDB Community Server unless it is a publicly available MongoDB as a service. The copyleft condition of Section 13 of the SSPL does not apply to companies building other applications or a MongoDB as a service offering for internal-only use.
Source https://www.mongodb.com/licensing/server-side-public-license/faq
-
@necrevistonnezr said in Why not make Cloudron fully open source again?:
make the functionality of the Program (…) available to third parties
This means directly. When you host an app that uses MongoDB in the back-end, you are making the app itself available, not mongodb, so no, it does not apply.
CF this citation from Mongo's own FAQ about SSPL:
Does section 13 of the SSPL apply if I’m offering MongoDB as a service for internal-only use?
No. We do not consider providing MongoDB as a service internally or to subsidiary companies to be making it available to a third party.
Or also :
What will happen if someone in the community is currently building something on MongoDB Community Server?
There will be no impact to anyone in the community building an application using MongoDB Community Server unless it is a publicly available MongoDB as a service. The copyleft condition of Section 13 of the SSPL does not apply to companies building other applications or a MongoDB as a service offering for internal-only use.
Source https://www.mongodb.com/licensing/server-side-public-license/faq
@mehdi
The FAQ is not binding in any way. Only the license text is binding and (purposefully) vague (in order to create uncertainty and thus motivate companies to license).
As a lawyer, I would not recommend to built a business on the mere hope that implementing MongoDB code is conforming to the License Agreement. -
This is very interesting and relevant to this discussion:
https://autonomic.zone/blog/co-op-cloud/
Basically, a UK based worker co-op digital agency who used to use Cloudron no longer do so and have now started yet another project to fulfil very similar goals called Co-op Cloud.
This is primarily because Cloudron is no longer open source.
I really love their project and wish them well and will do all I can to support them, but I can't help also feeling a bit sad that it needs to exist at all.
I reckon if Cloudron had remained open source their energy could been usefully put into helping to improving Cloudron rather than starting another project.
-
This is very interesting and relevant to this discussion:
https://autonomic.zone/blog/co-op-cloud/
Basically, a UK based worker co-op digital agency who used to use Cloudron no longer do so and have now started yet another project to fulfil very similar goals called Co-op Cloud.
This is primarily because Cloudron is no longer open source.
I really love their project and wish them well and will do all I can to support them, but I can't help also feeling a bit sad that it needs to exist at all.
I reckon if Cloudron had remained open source their energy could been usefully put into helping to improving Cloudron rather than starting another project.
@jdaviescoates said in Why not make Cloudron fully open source again?:
Co-op Cloud
It's an interesting, but also really quite different approach. I like cloudron because it's so "hands off". Their system really just seems to be a deployment utility for docker swarm along with a standardised way of deployment.
-
This is very interesting and relevant to this discussion:
https://autonomic.zone/blog/co-op-cloud/
Basically, a UK based worker co-op digital agency who used to use Cloudron no longer do so and have now started yet another project to fulfil very similar goals called Co-op Cloud.
This is primarily because Cloudron is no longer open source.
I really love their project and wish them well and will do all I can to support them, but I can't help also feeling a bit sad that it needs to exist at all.
I reckon if Cloudron had remained open source their energy could been usefully put into helping to improving Cloudron rather than starting another project.
@jdaviescoates I like that they are still using Cloudron. It's interesting to me that their user-initiated installation all takes place on and from the local machine, not the server. That actually worries me because if my laptop dies, and I haven't made that most recent backup, what happens to my server setup? I like that Cloudron can do its work on the server. Of course, this point has not alot to do with their reason (morr libre) for trying to move away from Cloudron. I just thought I'd check out the blog and the service since you mentioned it. Seems easier to use than caprover, albeit with far fewer ready-to-go apps.
-
Thanks for your elaborate post, we will answer in more detail, but till that, maybe the reversed question could also be asked to add more context your question: What are the hoped for benefits for users to have Cloudron under some open source license?
Please note that the code as such is source available, so there is no benefit from an introspection and code verification point of view at least.@nebulon I have been following this conversation and testing Cloudron for over a year. I would like to see it fully open source for the same reason that Wordpress and Joomla CMS tools are fully open source: more people will use it and create a larger ecosystem that floats all boats. I for one would like to use Cloudron white-labeled on my own servers for hosting CMS websites and email for small businesses. Cloudron, as easy as it is, is still way too complex for the average small business owner or even their web guys. I host several hundred sites for small businesses and they generally "have a web guy" or an agency that they pay to "handle the website and email". Usually there is one person in a small company or organization who might want to login to Wordpress to post updates but beyond that it's too technical. Even maintaining plugin updates and backups are "handled by our web guy" from their perspective but they usually fall behind and eventually get hacked. So my goal is to build a better tool for web guys that have lots of small business hosting clients like myself. But at the moment I don't see a path forward for fully running Cloudron on my own servers for "web guys" and small agencies, so I'm hesitant to pursue it and I'm exploring alternatives, but it is very close to what I would like to provide if I can find a way to make it work.
-
@nebulon I have been following this conversation and testing Cloudron for over a year. I would like to see it fully open source for the same reason that Wordpress and Joomla CMS tools are fully open source: more people will use it and create a larger ecosystem that floats all boats. I for one would like to use Cloudron white-labeled on my own servers for hosting CMS websites and email for small businesses. Cloudron, as easy as it is, is still way too complex for the average small business owner or even their web guys. I host several hundred sites for small businesses and they generally "have a web guy" or an agency that they pay to "handle the website and email". Usually there is one person in a small company or organization who might want to login to Wordpress to post updates but beyond that it's too technical. Even maintaining plugin updates and backups are "handled by our web guy" from their perspective but they usually fall behind and eventually get hacked. So my goal is to build a better tool for web guys that have lots of small business hosting clients like myself. But at the moment I don't see a path forward for fully running Cloudron on my own servers for "web guys" and small agencies, so I'm hesitant to pursue it and I'm exploring alternatives, but it is very close to what I would like to provide if I can find a way to make it work.
@danboarder FWIW I've been in the web business 20 years, and probably used every server control panel and managed/wordpress hosting, and none compare to the ease and value of Cloudron - for this web guy at least.
I don't know why the source code licence would stop you doing anything you want.
It sounds to me like you have the same options we all went through to end up here and happier.
I'm happy to recommend, and think you'll find Cloudron very time-liberating - but I can't see why the licence model would stop you using it?
Every action has a reaction, and every choice has an opportunity cost.
I guess your options are things like host server control panels like Plesk, managed services like Cloudways. Best I can say is I've been through those and time and gotchyas with those brought me here.
Personally, life experience tells me there's more than enough to do in business, if you have something that solves 90%+ of one area, you've probably got other areas that the freed up time would help you to get to 90%+ solutions in those other areas sooner than holding out for 100% solutions every time.
Don't know if that helps but then I didn't quite get the relationship between a common use-case and what that has to do with the licence model.
Maybe worth considering that being mass-market isn't always a good thing? Wordpress & Joomla for me are 90% wading through poor plugins, themes and bullshit marketing to find the small percent of things that are actually good. Focus trumps spray & pray every time in my world.
-
@jdaviescoates, thanks for the shout-out. I'd been meaning to hop over here and let people know about Co-op Cloud, but you beat me to it!
(Writing here in my personal capacity as a Co-op Cloud hacker, not speaking for Autonomic or for the project)
I'm personally really grateful that Cloudron exists, and the Cloudron team has been super-supportive to Autonomic over the years. Again, not speaking for the coöp, but I don't think we're fixin' to stop using Cloudron completely
You're absolutely right that the licence change was a huge factor in motivating me to help make Co-op Cloud, though – I'm proud that Autonomic had otherwise strictly avoided using proprietary software for our own infrastructure, and I share your sadness that we're maybe reinventing a wheel when there's such a great option available already
That said, it's totally Cloudron's prerogative to re-license, and I wish them every continued success with the closed model 
@fbartels, I think you're absolutely right that Cloudron is intended for a different group of people than Co-op Cloud is: I think Cloudron will continue to be a better "hands off" option, especially for people who don't know or don't like the command-line
To me, the main exciting things about Co-op Cloud are being able to keep your configuration in version control, using
docker-compose(i.e. multi-service) format instead ofDockerfileformat to package apps, and the licence. I guess, as @marcusquinn is saying, that there'll be many people who'll be more interested in the ease-of-use and automation of Cloudron, than that stuff.@fbartels I'd also agree with you about what Co-op Cloud is:
a deployment utility for docker swarm along with a standardised way of deployment.
I'd just add that, as well as those two things, it's a collection of 30+ applications packaged using that format
https://docs.cloud.autonomic.zone/apps/Lastly, @scooke, that's a really good point about where the data is stored:
It's interesting to me that their user-initiated installation all takes place on and from the local machine, not the server. That actually worries me because if my laptop dies, and I haven't made that most recent backup, what happens to my server setup?
Co-op Cloud has a (so-far-undocumented) feature to mitigate this: you can store the
~/.abra/servers/directory which contains app definitions in version control, or even symlink to folders in different repositories, if you have maintain different sets of apps with different servers with different teams. I use this myself and it works great, with minimal risk of losing work if my computer blows up.A next step would be to auto-deploy the apps based on changes to repositories, which is something I'd like to add in time for the beta.
One other alternative (also not yet documented), which I'm also using on one project, is that you can install and run Co-op Cloud on the VPS you're managing – in which case the app definitions live on the server just as you're saying.
Caprover is definitely pretty similar: I'd started a comparison between it and Co-op Cloud but it doesn't look like it's made it into the docs yet. Watch this space!
-
@jdaviescoates, thanks for the shout-out. I'd been meaning to hop over here and let people know about Co-op Cloud, but you beat me to it!
(Writing here in my personal capacity as a Co-op Cloud hacker, not speaking for Autonomic or for the project)
I'm personally really grateful that Cloudron exists, and the Cloudron team has been super-supportive to Autonomic over the years. Again, not speaking for the coöp, but I don't think we're fixin' to stop using Cloudron completely
You're absolutely right that the licence change was a huge factor in motivating me to help make Co-op Cloud, though – I'm proud that Autonomic had otherwise strictly avoided using proprietary software for our own infrastructure, and I share your sadness that we're maybe reinventing a wheel when there's such a great option available already
That said, it's totally Cloudron's prerogative to re-license, and I wish them every continued success with the closed model @fbartels, I think you're absolutely right that Cloudron is intended for a different group of people than Co-op Cloud is: I think Cloudron will continue to be a better "hands off" option, especially for people who don't know or don't like the command-line
To me, the main exciting things about Co-op Cloud are being able to keep your configuration in version control, using
docker-compose(i.e. multi-service) format instead ofDockerfileformat to package apps, and the licence. I guess, as @marcusquinn is saying, that there'll be many people who'll be more interested in the ease-of-use and automation of Cloudron, than that stuff.@fbartels I'd also agree with you about what Co-op Cloud is:
a deployment utility for docker swarm along with a standardised way of deployment.
I'd just add that, as well as those two things, it's a collection of 30+ applications packaged using that format
https://docs.cloud.autonomic.zone/apps/Lastly, @scooke, that's a really good point about where the data is stored:
It's interesting to me that their user-initiated installation all takes place on and from the local machine, not the server. That actually worries me because if my laptop dies, and I haven't made that most recent backup, what happens to my server setup?
Co-op Cloud has a (so-far-undocumented) feature to mitigate this: you can store the
~/.abra/servers/directory which contains app definitions in version control, or even symlink to folders in different repositories, if you have maintain different sets of apps with different servers with different teams. I use this myself and it works great, with minimal risk of losing work if my computer blows up.A next step would be to auto-deploy the apps based on changes to repositories, which is something I'd like to add in time for the beta.
One other alternative (also not yet documented), which I'm also using on one project, is that you can install and run Co-op Cloud on the VPS you're managing – in which case the app definitions live on the server just as you're saying.
Caprover is definitely pretty similar: I'd started a comparison between it and Co-op Cloud but it doesn't look like it's made it into the docs yet. Watch this space!
@3wordchant Thank you for dropping in and sharing. Even though the topic here has been "which licence Cloudron uses", I am super keen for people be able to take control over their own data and manage it. I've slowly been disentangling myself from Facebook (actually did this 3 years ago), Instagram, Zoom, and have even started separating from gasp Google. I have Cloudron on more than one server; I even used Caprover*, which, despite its relative complexity, was useful for setting up and testing poste-io, wordpress was a breeze, etc. It is heartening to read your kind and enthusiastic words to the Cloudron team.
*I had to poke around to find the apps available on caprover: https://github.com/caprover/one-click-apps/tree/master/public/v4/apps)
-
@jdaviescoates, thanks for the shout-out. I'd been meaning to hop over here and let people know about Co-op Cloud, but you beat me to it!
(Writing here in my personal capacity as a Co-op Cloud hacker, not speaking for Autonomic or for the project)
I'm personally really grateful that Cloudron exists, and the Cloudron team has been super-supportive to Autonomic over the years. Again, not speaking for the coöp, but I don't think we're fixin' to stop using Cloudron completely
You're absolutely right that the licence change was a huge factor in motivating me to help make Co-op Cloud, though – I'm proud that Autonomic had otherwise strictly avoided using proprietary software for our own infrastructure, and I share your sadness that we're maybe reinventing a wheel when there's such a great option available already
That said, it's totally Cloudron's prerogative to re-license, and I wish them every continued success with the closed model @fbartels, I think you're absolutely right that Cloudron is intended for a different group of people than Co-op Cloud is: I think Cloudron will continue to be a better "hands off" option, especially for people who don't know or don't like the command-line
To me, the main exciting things about Co-op Cloud are being able to keep your configuration in version control, using
docker-compose(i.e. multi-service) format instead ofDockerfileformat to package apps, and the licence. I guess, as @marcusquinn is saying, that there'll be many people who'll be more interested in the ease-of-use and automation of Cloudron, than that stuff.@fbartels I'd also agree with you about what Co-op Cloud is:
a deployment utility for docker swarm along with a standardised way of deployment.
I'd just add that, as well as those two things, it's a collection of 30+ applications packaged using that format
https://docs.cloud.autonomic.zone/apps/Lastly, @scooke, that's a really good point about where the data is stored:
It's interesting to me that their user-initiated installation all takes place on and from the local machine, not the server. That actually worries me because if my laptop dies, and I haven't made that most recent backup, what happens to my server setup?
Co-op Cloud has a (so-far-undocumented) feature to mitigate this: you can store the
~/.abra/servers/directory which contains app definitions in version control, or even symlink to folders in different repositories, if you have maintain different sets of apps with different servers with different teams. I use this myself and it works great, with minimal risk of losing work if my computer blows up.A next step would be to auto-deploy the apps based on changes to repositories, which is something I'd like to add in time for the beta.
One other alternative (also not yet documented), which I'm also using on one project, is that you can install and run Co-op Cloud on the VPS you're managing – in which case the app definitions live on the server just as you're saying.
Caprover is definitely pretty similar: I'd started a comparison between it and Co-op Cloud but it doesn't look like it's made it into the docs yet. Watch this space!
@3wordchant This is really exciting. Thank you for sharing this project!
-
@nebulon I can't speak for @jdaviescoates, but I would point out just 4 benefits:
- Greater Contributions. With a source available, but proprietary license, anyone who contributes a bug fix or feature immediately loses license to their own work, or at least would have to in order for Cloudron to be able to enforce its license and copyright. Aside from the potential legal mess, this is almost certainly a deterrent to substantial outside contributions. An open source license makes Cloudron much more enticing to contribute to.
- Benefits of Broad Adoption. Those willing to do the work to run their own Cloudron instance from the source code may have been loud, but they weren't likely customers to begin with. While not paying, these potential users do offer some benefits. They're more likely to provide good bug reports, patches, and answers to community questions. Even while promoting the free use of Cloudron, they are reaching an audience you would otherwise have to pay to reach. Even if the vast majority of users were to use Cloudron for free, as I suspect the majority of Nextcloud users do, in volume it really becomes a net benefit to Cloudron.
- Long-Term Assurance. The choice to self-host one's own infrastructure can be stressful. It becomes less stressful when you know that the software your using is open source and will be viable as long as there is a community willing to keep it going. This is one reason open source users become such loud advocates. They want that thriving community to live on forever, in a way they can't necessarily ensure a company will.
- Part of a Bigger Cause. I like you @nebulon and @girish. I like what you have made, and I hope you succeed, probably more so than most companies I buy products/services from. But at the end of the day you are a company. People like companies, they support causes. It's hard for me to express how when Cloudron went from open source to proprietary it changed my feelings. I still tell people about it and have tried to make important strategic introductions. But I don't donate my time to Cloudron like I do Inkscape. I don't extol the virtues of Cloudron over all other proprietary solutions, like I do Nextcloud. Supporting a company selling a proprietary solution is just not the same as supporting a company that is part of a bigger cause. Cloudron has the potential to be part of that cause. I want it to be open source.
Addendum: This is all said with full awareness that you need and deserve to get paid. Don't listen to anyone who expects anything otherwise. For the reasons stated above, and others, I think you can still make a living and perhaps even a better living releasing software with an open source license.
There are many advantages to open source, but if I could point the most important to me in this case, it would be this one already mentioned by @ryangorley:
- Long-Term Assurance. The choice to self-host one's own infrastructure can be stressful. It becomes less stressful when you know that the software your using is open source and will be viable as long as there is a community willing to keep it going. This is one reason open source users become such loud advocates. They want that thriving community to live on forever, in a way they can't necessarily ensure a company will.
Whether I'm contributing apps or fixes as a:
- User (because I use Cloudron for my personal needs)
- Company (because I deploy Cloudron to my customers)
- App Author (because I want my app to be available in Cloudron)
I don't want my investment (
+ 
) to go to waste if Cloudron UG (the company), in the future:- decides to change its terms in a certain way that don't fit my needs (or that I simply can't afford money-wise)
- is bought out by a company that has a different approach/view
- simply goes under
And to top it off, I would have to abruptly migrate all my apps to a different platform, costing me even more
+ .But I still wish the best to the Cloudron team, which is doing an amazing job!
-
There are many advantages to open source, but if I could point the most important to me in this case, it would be this one already mentioned by @ryangorley:
- Long-Term Assurance. The choice to self-host one's own infrastructure can be stressful. It becomes less stressful when you know that the software your using is open source and will be viable as long as there is a community willing to keep it going. This is one reason open source users become such loud advocates. They want that thriving community to live on forever, in a way they can't necessarily ensure a company will.
Whether I'm contributing apps or fixes as a:
- User (because I use Cloudron for my personal needs)
- Company (because I deploy Cloudron to my customers)
- App Author (because I want my app to be available in Cloudron)
I don't want my investment (
+ ) to go to waste if Cloudron UG (the company), in the future:- decides to change its terms in a certain way that don't fit my needs (or that I simply can't afford money-wise)
- is bought out by a company that has a different approach/view
- simply goes under
And to top it off, I would have to abruptly migrate all my apps to a different platform, costing me even more
+ .But I still wish the best to the Cloudron team, which is doing an amazing job!
@gabrielcossette If you can't afford Cloudron, you probably have bigger problems.
I'm an open-source first person too, but the source code is available, so I think that the reasoning is that the current team need to focus more on development than discussion, and open-source comes with a lot of admin overhead for discussion and rights-management.
I'm sure that will change in future, but probably just easier just not to get involved in all of that for now if we want all the main wish-list development things done any time soon.
Web Design https://www.evergreen.je
Development https://brandlight.org
Life https://marcusquinn.com -
@gabrielcossette If you can't afford Cloudron, you probably have bigger problems.
I'm an open-source first person too, but the source code is available, so I think that the reasoning is that the current team need to focus more on development than discussion, and open-source comes with a lot of admin overhead for discussion and rights-management.
I'm sure that will change in future, but probably just easier just not to get involved in all of that for now if we want all the main wish-list development things done any time soon.
@marcusquinn said in Why not make Cloudron fully open source again?:
@gabrielcossette If you can't afford Cloudron, you probably have bigger problems.
Maybe I didn't word it correctly, but that's not what I meant. I wanted to express that Cloudron terms and pricing could change in the future, in a way that could not be appropriate anymore for some users. And as the platform is not open source, you have no choice than migrating to a different platform.
It's all about risk management.
Personally, I find it too risky to host all my digital infrastructure on a platform that doesn't provide a good exit strategy.[...] open-source comes with a lot of admin overhead for discussion and rights-management.
As long as you manage expectations, you can do open source and not burn you out.
You could state: "Hey, feel free to use the code, ask questions and make contributions, but as our team has limited resources (for now), we can't make any promise regarding support. Also, if you are interested in reliable support, check out our commercial offer.
" -
J jdaviescoates referenced this topic on
-
Looks like someone else has a neat FOSS Cloudron alternative to compare and run a few apps missing here: https://github.com/meienberger/runtipi
Web Design https://www.evergreen.je
Development https://brandlight.org
Life https://marcusquinn.com -
Looks like someone else has a neat FOSS Cloudron alternative to compare and run a few apps missing here: https://github.com/meienberger/runtipi
@marcusquinn Perhaps their dockerfiles help with packaging here or at least easier adoption from pure code sources.
-
Looks like someone else has a neat FOSS Cloudron alternative to compare and run a few apps missing here: https://github.com/meienberger/runtipi
@marcusquinn said in Why not make Cloudron fully open source again?:
Looks like someone else has a neat FOSS Cloudron alternative to compare and run a few apps missing here: https://github.com/meienberger/runtipi
Quite a few similar things have been shared in various posts on this forum previously. I feel collectively we could put together a pretty comprehensive list of Cloudron alternatives/ competitors, and that we should. I think I may have even previously started a thread to that end...
-
@marcusquinn said in Why not make Cloudron fully open source again?:
Looks like someone else has a neat FOSS Cloudron alternative to compare and run a few apps missing here: https://github.com/meienberger/runtipi
Quite a few similar things have been shared in various posts on this forum previously. I feel collectively we could put together a pretty comprehensive list of Cloudron alternatives/ competitors, and that we should. I think I may have even previously started a thread to that end...
@jdaviescoates said in Why not make Cloudron fully open source again?:
I think I may have even previously started a thread to that end...
But if I did, I can't find it! Must've dreamt it
-
@jdaviescoates said in Why not make Cloudron fully open source again?:
I think I may have even previously started a thread to that end...
But if I did, I can't find it! Must've dreamt it
But I know e.g. @scooke has posted other alternatives too, like e.g. Ethibox https://github.com/ethibox/ethibox
-
@marcusquinn said in Why not make Cloudron fully open source again?:
Looks like someone else has a neat FOSS Cloudron alternative to compare and run a few apps missing here: https://github.com/meienberger/runtipi
Quite a few similar things have been shared in various posts on this forum previously. I feel collectively we could put together a pretty comprehensive list of Cloudron alternatives/ competitors, and that we should. I think I may have even previously started a thread to that end...
@jdaviescoates said in Why not make Cloudron fully open source again?:
and that we should
But with what goal? To make people switch away from Cloudron? Seems quite an inappropriate topic for this forum.
There for sure are quite some solutions with similar features. Some platforms are very developer centric, some platforms focus on downloading pirated content, but what most of the systems are missing is a comprehensive user management and unified login. And of course the backup and restore functionality that Cloudron provides.
What I can run with Cloudron, I run with Cloudron. And what does not work, is deployed as a separate environment.
-
@jdaviescoates said in Why not make Cloudron fully open source again?:
and that we should
But with what goal? To make people switch away from Cloudron? Seems quite an inappropriate topic for this forum.
There for sure are quite some solutions with similar features. Some platforms are very developer centric, some platforms focus on downloading pirated content, but what most of the systems are missing is a comprehensive user management and unified login. And of course the backup and restore functionality that Cloudron provides.
What I can run with Cloudron, I run with Cloudron. And what does not work, is deployed as a separate environment.
@fbartels
I've looked at lots of other "similar" offerings.
None of them come anywhere near close to Cloudron in terms of performance, stability, value for money etc.Being fully open source is a red-herring IMHO.
I just want Cloudron to work ... and it does.
Better than anything anywhere else. Simply no contest.
Just my 2p.
