OwnCloud came along at just the right time for me. I had decided to close my Google account and needed to find self-hosted software that would store my calendar and contacts and sync them to my devices.
OwnCloud did just that. DavDroid, installed on my Android devices, allowed me to sync both my contacts and calendar to OwnCloud. My replacement mail client, Roundcube, synced my contacts with it thanks to its CardDav integration. All was well.
For a bit...
As with any open source software, one of its benefits can also be its downfall. The ability to change direction and respond to user needs or the operating environment means open source software can stay fresh and relevant. But, this same ability can also mean a change for the worse, at least for some users.
There are better sources out there that relate the actual events, but OwnCloud development seemed to stagnate. The developers took the software in a different direction from what the majority of users seemed to want. They also decided to remove the calendar and contacts apps from the core software, leaving them to become unsupported extensions. A group of developers had a different idea for the future of OwnCloud and created a fork of the codebase. They called it NextCloud.
I tested NextCloud for a few months without switching completely from OwnCloud. I wanted to see how it progressed in its early life. It was also more than I needed. It was a full cloud solution, providing file storage and a selection of apps that supported hundreds of possible use cases. This made it a large piece of software. Much larger than it needed to be for my own personal uses.
It looked good for a while though, but the moment that I decided to look for an 'alternative replacement' came when I saw a video update on the Calendar app from the 2016 NextCloud conference, which discussed the software's new reliance on JavaScript.
Bloat?
Now, Georg Ehrke and Raghu Nayar probably (definitely) know a lot more about developing web applications than I do, but the switch to using JavaScript on the client as opposed to PHP on the server concerns me.
Yes, I understand that the old code was likely messy and not optimised very well. And yes, I understand that the pie chart probably illustrates a change in the optimisation of the PHP and it's now leaner, taking up less of a share of the overall codebase. But I can't help recalling the articles that keep cropping up, with greater frequency, about JavaScript bloat.
Since 2015, far-sighted developers have alerted their peers to the risks of increased reliance on JavaScript. Maciej Cegłowski gave a talk at the 2015 Web Directions conference in Sydney where he covered a selection of examples. Yes, they include Medium.
If you're developing web apps on the latest, flashy Mac, of course it's going to be fast. But what about users on old devices: phones, tablets, computers, e-readers (yes, people use those to browse the web), set-top boxes, consoles, etc?
Placing the load on the client device rather than the server is never going to solve problems. It will simply accelerate device obsolescence and increase frustration, annoyance and maybe waste at the user end.
My personal solution
Remember when this article was about my Cal and CardDav requirements instead of a rant?
I dropped OwnCloud as well as my planned switch to NextCloud. Instead, I've installed Baikal. It's a CalDav and CardDav server and admin tool, and that's all it is. Nothing more than is needed to store and sync my calendars and contacts and allow me to manage the system itself. It doesn't have a calendar or contact client. I have clients on my devices for those.
So, my server is now much lighter, and my software is more specific and targeted to my needs.
Let's see how it goes.