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.
There is also https://cloudron.io/ to self-host, which provides a complete email solution based on dovecot and haraka plus a couple of webmail apps to use, like rainloop and roundcube.
Currently we are not in a position to do this, it would be great of course. At the moment we do contribute to the upstream projects.
Please note, what we have is not a true app store with pay-per-app, but the subscription is to ensure we have the resources to package, test and support the apps on Cloudron. We have elaborate unit tests for each app as well as do manual testing, since we want to deliver a saas style update experience.
As you said, you wont get further updates to the apps, however everything will continue to run as is. Also you will be able to further manage the server or reconfigure already installed apps. Other features like automatic backups will also keep working.
At Cloudron.io, we track the releases of hundreds of apps on GitHub. We used to use a service called sibbell.com for this but they shutdown recently. We wrote Release Bell as an alternative.
Essentially, it monitors all your starred GitHub projects and sends you an email notification when a new release is available.
The project is self-hosted, so (obviously) we packaged it for Cloudron. You can install Release Bell on your Cloudron or take a look at the demo instance - https://demo.releasebell.com (username: releasebell password: releasebell) The app does not have any special demo mode to protect the settings, I will try to reset it if needed. Also given the purpose of the app to simply send notifications, we kept the UI minimal.