Piping in here late, but I believe this discussion has potential 
so let me add my 2 cents…
There are a lot of ‘collaboration tools’ out there, either for techies/programmers, for business operations, for ticketing and tech support, and so forth; all of them, to a degree, allow multiple users to share files, sometimes with versioning, often with indexing abilities, tagging and so forth. Each, however, is tailored for a particular purpose. For instance, you could use, say, GitHub (or a clone of it, like gogs, which is my favourite) to get similar features. It would be a very creative use of git, but it would work; and, in fact, many solutions use the git protocol to deal with versioning and sync’ing, for instance.
Now, when I first started to use ownCloud and similar services what I wanted was a Dropbox replacement, and I can imagine that most people expected the same from such services. I settled on Pydio mostly because, at the time I’ve tested it, it was the one that suited my purposes best, worked quite well out of the box, had all the ‘right’ features I needed, and was based on PHP, which, at the time, I rather preferred over alternatives in Perl, Python, or — ugh! — Java. (You really need to do long-time maintenance on solutions using those kinds of platforms to truly appreciate how easy it is to do things under PHP…)
The conceptual ‘future-proof’ change to Pydio Cells was a surprise to me, and one that I actually liked a lot! By sheer coincidence, a friend of mine who works for Google mentioned Go to me — he didn’t do much more than point out its existence. I learned it on my own and was immediately in love with it — not only because of its syntax but mostly because of the neat way it all fits together. Although over time I started to find out a few faults which most Go-haters have been pointing out for eons (most of which are actually Google developers, unhappy with being ‘forced’ to move to Go), for me it’s still the programming language of the present (I still like PHP, though, although I’m getting frustrated with the swiftness that things get obsoleted by the core programmers, and the way people do code in PHP these days resembles more and more the worst practices of Java and C# programmers, but that’s another story…). In fact, I ported a 3-year-old project in PHP — which was under development and not finished — to Go in about three months, from scratch, while I was still learning: it’s certainly not an ‘idiomatically correct’ usage of Go, but I couldn’t care less (I’m not a professional programmer): the point is that the project gained a ton of new features (because Go had them by default), and, because Go is compiled (and not interpreted-cum-JIT compilation) without needing dependencies, it was several orders of magnitude faster, more stable, and more easy to understand/fix/add things to it. Even spaghetti code in Go looks great! 
When I first heard that Pydio was using a ‘Go backend’ to deal with sync’ing, I was impressed. A few years ago, die-hard PHP programmers, requiring some similar functionality which PHP was not adequately providing, would (possibly) add a Java thingy. Which would then have a gazillion dependency issues and work only on very specific environments. Which in turn would leave a lot of people behind (possibly switching to another platform…). Well, that would be a worst-case scenario, of course, but I’ve seen it happening in other applications/platforms. And I’ve abandoned a few exactly because of that.
Whew, long introduction… but here is my point: moving from PHP-based Pydio to a Go implementation, rewritten from scratch (and actually with a completely different conceptual framework), is, for me, the way to go (pun intended, of course! 
). Sure, it means that Pydio Cells will lag behind PHP-based Go for a while, simply because it takes time to ‘catch up’ with the tons of lines of code currently in Pydio 8. I miss many of the plugins, for instance, and obviously they will not work ‘soon’ with Pydio Cells, since the original developers will need to learn Go and the new development paradigm. On the other hand, I also feel that Pydio Cells is not an unfinished product — rather, it feels like a ‘late beta’, good enough to deploy in production but missing the occasional bells & whistles, which I’m sure it will get ‘sooner or later’.
However, there is a crucial difference — unless I’ve misunderstood @charles. PHP-based Pydio was developed as a ‘Dropbox replacement’ where desktop sync’ing is crucial, not merely a nice little useful feature. Remote sync’ing is what Dropbox is for — and Pydio replicated that concept neatly. We can argue if the sync’ing was slower/less efficient/consumed more resources on the client and/or the server, compared to Dropbox, but… it worked. Or rather, it still works, and while I’m sure everything can be improved at some point, it does what it’s supposed to do.
I was startled to learn that PydioSync did not support Pydio Cells (when the iOS app has no problem whatsoever to connect to it). In fact, for days I thought I had misconfigured something — namely, the certificates — because all I got were HTTPS errors. Eventually, I found this thread and understood that there was no problem with my configuration, it’s just that Pydio Cells, unlike Pydio 8, is not meant to be a Dropbox replacement but… well, a slimmed down version of Pydio 8, I guess, one that misses crucial functionality — I would even go as far as claiming it to be the core functionality, because, well, in my case, I started using Pydio because sync’ing is all I wanted.
As said, there are plenty of ‘remote folder’ solutions out there. And technically one could simply use Unison to do remote sync’ing, and possibly wrap a GUI around it, and that would be all. But Pydio is much more than that — rather, let me rephrase that: Pydio used to be much more than that, while still catering to our basic needs, i.e. sync’ing to a Dropbox-style remote environment.
It’s been around three months since @charles mentioned that PydioSync would support Cells (or, alternatively, that a new method of sync’ing would be deployed). I wonder if there is any news on the state of the development? Is the 4-6 months timescale still feasible?
. It may just not fit the needs at a given point.
