Good job to the authors. I have been waiting for something like that for years.
I just dislike the scripted languages as they are a mess to handle while docker is a resource waste, not to mention golang single statically compiled binary and speed of execution.
Authors, please think really well about:
- upgrade strategies (owncloud/nextcloud were a huge mess, for long time, currently looks that nextcloud is handling it well - I have upgraded it for 2 versions and it didnt break anything)
- what external dependencies you are using, make additional layer of OS abstraction to avoid incompatibilities between various linux distributions, freebsd and windows. There isn't a lot to handle differently but once you tie yourself to linux only, it is hard to add support afterwards (try to not call external binaries that you havent installed yourself, if you must, put it into compatibility layer). If you do this one right, people will port it to different environments, if you blow it, you will have to - or you wont.
- do not rely on docker "installation", presume that it is installed directly on the system and you wont go far wrong. Treat docker just as another system. Docker is going to make you become "lazy" to not think about vital details while developing.
- do check how to handle reverse proxies gracefully, this is something everyone forgets while for any serious environment, there will be nginx frontend
- dont support all the databases, pick one and stick to it, to support it really well, including backups, upgrades and versions
- sooner or later redis is going to be a must, think upfront
- make a backup system, backup before upgrades and be sure you can restore it if something goes wrong, including binaries, database,...
- make an installation/upgrade layer that doesn't depend on "run this sql script", have a well versioned database revision system that can get database from version "0.1" to "2.0" without breaking anything and migrate the data. There are hardly any database changes where database upgrade cant be handled with sql statements.
- think really well about external dependencies, dont pick it just as it is popular and you need one functionality. An example, recently I did a benchmark of 15 concurrent maps in go and the differences were huge where the fastest one was one that you can hardly find by searching while the author did things like aligning the structures with cpu cache, full of unsafe pointers etc., but beating the first selected "popular" map by 2x, and the worse by 15x+. Dont trust authors self promotion, measure it.
- try to not make it confusingly strange, you have the whole usage/administration well done with nextcloud, stick to it, dont reinvent what works, as for instance, sftpgo did and I hate every second using it.
- if something needs to be documented, think about how to implement it, in a way, that doesnt need to be documented. Over time those documented features become a huge burden for you and for users.
- please, if you dethrone nextcloud, dont become evil, like projects normally do. Get the money from where the money is (smb, corporations), spare the home users. :)
The product seems more 'focused' than Nextcloud, for sure.
But their docker choices are quite opinionated: no longer than yesterday I've tried (once again!) to make it run, and the fact that I have Caddy + Authelia in front of seems to be rather detrimental. I dropped the ball, and will try again in a few weeks or months.
I just dislike the scripted languages as they are a mess to handle while docker is a resource waste, not to mention golang single statically compiled binary and speed of execution.
Authors, please think really well about:
- upgrade strategies (owncloud/nextcloud were a huge mess, for long time, currently looks that nextcloud is handling it well - I have upgraded it for 2 versions and it didnt break anything)
- what external dependencies you are using, make additional layer of OS abstraction to avoid incompatibilities between various linux distributions, freebsd and windows. There isn't a lot to handle differently but once you tie yourself to linux only, it is hard to add support afterwards (try to not call external binaries that you havent installed yourself, if you must, put it into compatibility layer). If you do this one right, people will port it to different environments, if you blow it, you will have to - or you wont.
- do not rely on docker "installation", presume that it is installed directly on the system and you wont go far wrong. Treat docker just as another system. Docker is going to make you become "lazy" to not think about vital details while developing.
- do check how to handle reverse proxies gracefully, this is something everyone forgets while for any serious environment, there will be nginx frontend
- dont support all the databases, pick one and stick to it, to support it really well, including backups, upgrades and versions - sooner or later redis is going to be a must, think upfront
- make a backup system, backup before upgrades and be sure you can restore it if something goes wrong, including binaries, database,...
- make an installation/upgrade layer that doesn't depend on "run this sql script", have a well versioned database revision system that can get database from version "0.1" to "2.0" without breaking anything and migrate the data. There are hardly any database changes where database upgrade cant be handled with sql statements.
- think really well about external dependencies, dont pick it just as it is popular and you need one functionality. An example, recently I did a benchmark of 15 concurrent maps in go and the differences were huge where the fastest one was one that you can hardly find by searching while the author did things like aligning the structures with cpu cache, full of unsafe pointers etc., but beating the first selected "popular" map by 2x, and the worse by 15x+. Dont trust authors self promotion, measure it.
- try to not make it confusingly strange, you have the whole usage/administration well done with nextcloud, stick to it, dont reinvent what works, as for instance, sftpgo did and I hate every second using it.
- if something needs to be documented, think about how to implement it, in a way, that doesnt need to be documented. Over time those documented features become a huge burden for you and for users.
- please, if you dethrone nextcloud, dont become evil, like projects normally do. Get the money from where the money is (smb, corporations), spare the home users. :)
Good luck!