Developers Using Their Own Clients

Do Nextcloud desktop client developers actually use the client themselves? In my case: not as much as you would expect, and there are reasons which are as surprising as they are boring.

The following insights are not specific to my employment at Nextcloud GmbH but also my previous job at Open-Xchange GmbH where I worked on OX Drive. Please note that this is my personal experience, it varies for everyone, also among developers and external contributors.

Daily Business

99% of the data I work with on a daily basis are source code files. Those are usually managed by a source code version control system like Git, not a file synchronization solution like Nextcloud. This is fine because those are two different solutions for different tasks.

Every few months I edit a spreadsheet template to request reimbursement of travel expenses. I have not created a presentation in a long time. And there simply are no situations in which I need a typical office word processor in scope of my work. I cannot recall the last time; it must be years. Though, to mention examples, I do edit notes or pages in Nextcloud Notes and Nextcloud Collectives. However, I do that in the Nextcloud web user interface instead, as another form of dogfooding.

Now, obviously, there are not many situations in which I actually get to work with plain files to synchronize with something like the Nextcloud desktop client or whatever compares to it. And if I have to test something, I surely do not use a production server instance as the backend for that. Those usually do not have the same complexity and volume of data as production environments do.

Clean Environment

File providers are system-level extensions on macOS. When they were introduced with macOS 12, there were a lot of stumbling blocks and some instability. Not having multiple builds of the same app and its file provider extension installed on the same macOS installation solved some of them. macOS loads extensions rather eagerly based on different heuristics, even from the trash.

Sometimes third-party extensions can break other third-party extensions as well. Do not ask me why.

I observed that with Dropbox and Adobe Creative Suite in the past. When I work on the Nextcloud file provider extension, I make sure that I do not have any other unnecessary file provider (or any extension in general) installed.

So, while being in the change-build-run feedback loop of programming, it is best to not have another build running in parallel, because in the worst case it will cost a lot of debugging time just to figure out that things got wired up incorrectly.

Private Life

My private life looks completely different. Almost since its introduction, I have used iCloud more and more, as it gained richer features over the years. A long time ago I used third-party products and services instead, but iCloud became sufficient at some point.

I even consider it important to have a good understanding how competing software works and what it offers. Dwelling in a self-made echo chamber comes with the risk of running in circles at some point and stalling in regard to innovative ideas. Just having free accounts on all available cloud services without actually using them as a daily driver does not give you a profound impression of them either. Using iCloud in combination with other Apple products sparks inspiration on how to improve Nextcloud in regard to integration.

Also, I have used Nextcloud in a small group with friends for creative collaboration and music production for almost a decade. It was a smooth ride with the Nextcloud community snap and later the Nextcloud All-in-One deployment. Never again did I have to sacrifice hours and hours of my free time to handle updates or backups. Our use case was rather simple: one big shared group folder, no customized permissions, and workflows that avoided conflicts by design.

In both regards, my personal usage would not resemble the reality of most Nextcloud users we receive feedback from. Even if I went all in on Nextcloud in my private life, it would not be helpful in discovering most of the problems I work on daily.

Many, if not most, problems arise from misconfigured Nextcloud (server) deployments. Hence, without detailed user data, it is a tough nut to crack why basic processes like remote change detection do not work as expected in the wild when they work just fine in our testing environments.

With this post, I hope to shed some light and understanding on why developers like me are not omniscient in regard to their software’s features and behaviors in an endless variety of environments.