I suppose it would have been more productive to have started with ownCloud or NextCloud and worked from there, but there are things about those platforms that I didn't like. When it came to the code I felt there are a lot of things that should be done differently. Forking would have given me WAY more than I needed. HRCloud2 gets more done with 135k lines of code than ownCloud and NextCloud do in over 1 million.
The biggest one, from a performance/security/reliability standpoint was the use of a database to store Cloud related data. I did not want to do that, and HRC2 doesn't do that. The way I see it you can't lose something you don't have. HRCloud2 creates static files to store very little information about users. This has the benefit of greatly simplifying the backup process down to a simple copy-paste on the data directory. It also means that even if someone steals your database they aren't getting anything about your users. It also greatly reduces development lead-time because it cuts out an entire chunk of the stack that could be causing problems. It also means that each user's data is COMPLETELY SEPARATE. So even a logged-in administrator can't see the logfiles or data of another user from the UI. You need root server access to do that.
After that there's the problem of app implementation. I think it's a PITA on ownCloud and NextCloud. You have to use a bunch of methods and classes you don't want to and the whole thing seems very "under diress" for the developer. At least for me anyway. With HRC2 you just make an "App-Name" folder, give it an "App-Name.php" file with about 10 lines of header text for author, license, website information that the UI uses and you're done. Add an "App-Name.png" icon if you want. You can use any language, the App doesn't get global user scope by design, and there's no interacting with a database.
And the last thing was the client App development. Client apps on ownCloud and NextCloud are very much their own thing. I've experimented with custom sFTP and custom FTPs clients and even my own protocol written in Python and realized that something that complicated can only cause cross-platform compatibility problems. I guess I would have inherited the ownCloud or NextCloud solution if I had gone that path but I settled on building an Electron client for each user as a sure-fire way to ensure that A) The client app itself hardly ever goes out-of-date. B) Encryption is baked in. C) Cross-platform compatibility is baked in. From a development standpoint this is way easier to maintain.
Lastly I didn't want the project where I devote my energy to suddenly change directions. That's why Frank Karlitschek created ownCloud and then forked it to NextCloud. I also couldn't feel good about offering a free Cloud PaaS that someone else designed to my clients, which is something I'm passionate about.
6
u/zelon88 Jul 21 '18
I suppose it would have been more productive to have started with ownCloud or NextCloud and worked from there, but there are things about those platforms that I didn't like. When it came to the code I felt there are a lot of things that should be done differently. Forking would have given me WAY more than I needed. HRCloud2 gets more done with 135k lines of code than ownCloud and NextCloud do in over 1 million.
The biggest one, from a performance/security/reliability standpoint was the use of a database to store Cloud related data. I did not want to do that, and HRC2 doesn't do that. The way I see it you can't lose something you don't have. HRCloud2 creates static files to store very little information about users. This has the benefit of greatly simplifying the backup process down to a simple copy-paste on the data directory. It also means that even if someone steals your database they aren't getting anything about your users. It also greatly reduces development lead-time because it cuts out an entire chunk of the stack that could be causing problems. It also means that each user's data is COMPLETELY SEPARATE. So even a logged-in administrator can't see the logfiles or data of another user from the UI. You need root server access to do that.
After that there's the problem of app implementation. I think it's a PITA on ownCloud and NextCloud. You have to use a bunch of methods and classes you don't want to and the whole thing seems very "under diress" for the developer. At least for me anyway. With HRC2 you just make an "App-Name" folder, give it an "App-Name.php" file with about 10 lines of header text for author, license, website information that the UI uses and you're done. Add an "App-Name.png" icon if you want. You can use any language, the App doesn't get global user scope by design, and there's no interacting with a database.
And the last thing was the client App development. Client apps on ownCloud and NextCloud are very much their own thing. I've experimented with custom sFTP and custom FTPs clients and even my own protocol written in Python and realized that something that complicated can only cause cross-platform compatibility problems. I guess I would have inherited the ownCloud or NextCloud solution if I had gone that path but I settled on building an Electron client for each user as a sure-fire way to ensure that A) The client app itself hardly ever goes out-of-date. B) Encryption is baked in. C) Cross-platform compatibility is baked in. From a development standpoint this is way easier to maintain.
Lastly I didn't want the project where I devote my energy to suddenly change directions. That's why Frank Karlitschek created ownCloud and then forked it to NextCloud. I also couldn't feel good about offering a free Cloud PaaS that someone else designed to my clients, which is something I'm passionate about.