Indeed as you mention, complex apps like Taiga are quite time-consuming to package in a way to ensure proper updates for the future. In fact I am right now in the process to iron out the update to Taiga v6 and that price-tag allows us to focus on such things so our users get a smooth experience without missing out on updates (disclaimer, I am one of the Cloudron founders :D )
For sake of our vision we surely would like to make it more cost-effective in the long run, however we are bootstrapped and thus walk a thin line with a focus more on long-term sustainability not just blind growth. (10x cheaper though would realistically even pose an accounting problem with micro-payments or plain transaction fees taking large chunks)
Cloudron also has a full email stack ready to go, however you are totally right about the residential IPs. They are basically all blacklisted by default, which is also why we had to add easy relay-provider support.
This looks really nice and the online demo is quite slick also on Firefox.
I saw that there is either a Qt or GL backend, which made me wonder how this is used then in the online demo or is the browser backend a third, undocumented one?
Also how is input (pointer, key) supported across the already apparently supported platforms?
While I tend to agree from a personal perspective, however the Wekan project especially seems to be able to pump out lots of very nice features at a high rate, thanks to meteor. Additionally to this, we at Cloudron update the app package about twice a week due to that and so far had very little breakage or regressions, compared to other apps. We do not update meteor often though, which is maybe contributing to the stability.
This is great to see and is pretty much the same reason why we have initially started with Cloudron [1]. There are not many technical reasons why running your own apps on the server has to be harder than using a phone. There are tons of great apps already out there and from my perspective the biggest issue, as mentioned in the blog post, is the onboarding and ease of installation/maintenance of those apps including the server itself. The building blocks are all available but as a complete solution hard to use, unless one is a kind of a sysamdmin. This makes it just very exclusive. If you ever tried to setup your own email server there is so much crud work to be done and things to be learned. Learning about this is as such a great opportunity to understand the underlying technology and how things work together, but it is also a huge barrier.
That is indeed a shame and I was also not aware of them shutting down some of their services. But as far as I know their text document editing tool is a slightly improved etherpad, which is mentioned in the article.
This looks great and would surely be a great addition. If you like, join us at https://chat.cloudron.io and we can together start working on an app package.
Since the whole stack runs on your server there is no real way to ban anyone as such. Worst case is that you would loose access to updates, however all our app packages are MIT licensed (eg. https://git.cloudron.io/cloudron/nextcloud-app ) as such you could just build the app image with docker locally and push to your server manually.
If you want to selfhost many of those apps, we have built a tool (Cloudron) to take away most of the deployment hassle for many of those apps mentioned in the link.
Also to work around the provider lock-in with ipv4 addresses while hosting from your home or on-premise we have a built-in dynamic DNS feature https://cloudron.io/documentation/networking/#dynamic-dns So in the end it doesn't matter if you change ISP or if you don't even have a static ipv4 as such.