I spent my first years in at Canonical working in the Ubuntu One project, particularly in what we always called "filesync": the pure file synchronization server (which was proprietary at that time), the client, and the protocol (both always open source).
Then, the company didn't push the project anymore, I started to work on other areas, and eventually the project was cancelled. When they cancelled it, they made the promise of opensourcing the server, which will allow to anyone put the full stack to work and have their own personal filesync cloud.
Time passed by, and at some point I got instructions to put daily time on that opensourcing work. I've been working the whole day on this for several weeks, and even more weeks part time, massaging all the code and dependencies for the project to be public. Then the project was released.
Was the project easily usable for anyone to start syncing files? Not really, my goals when working in the project to make it available for everybody were:
use only dependencies and libraries from a standard Ubuntu Precise environment and from freely available code from Launchpad
make testto pass ok, which means that further development can be easily startedmake start-oauthto start and work ok, which means that the server actually works and sync files
However, there's a lot to do for the service to be really used in a production environment where we can put our files and trust it, including but not limited to:
keep cleaning the project, lot of quirks and small weirdness to fix
make it to store files not in AWS but in the local filesystem
(after last item because some internal working reasons involving "resumable upload" that won't explain here) make it work in Trusty, or even in any modern (Ubuntu or not Ubuntu) environment
make it work nicely in a production environment (currently, for example, everytime it starts it uses a fresh database!)
simplify it: the server will not longer be used to hold a million users so features like use PostgreSQL in several shards are not worth it anymore
and several etceteras
Note that part of this work already started!! Naty Bidart and myself are working actively in some of those points.
Where? Well, with Natalia we already had the Magicicada Project, which was a GUI to interact with the client. So we forked the rest of the projects and naturally put them under that namespace.
So, the whole solution stack currently is:
Magicicada Server: the one that "lives in the cloud" and holds the files so all your clients can access them.
Magicicada Client: the application that runs in background in each of your computers, uploading/downloading new/changed files from/to the server.
Magicicada Protocol: a project with common code between client and server, particularly all the protocol implementation that allows them to talk each other.
Magicicada GUI: a small graphical utility that lets you interact and supervise what the client is doing in your computer.
All further work will be done in those projects. If you want to participate please suscribe to the mailing list or say hi in the IRC channel (#magicicada in Freenode). Also, you can file issues for any bug you find or new features/changes you want (be sure to choose the right project: server, client, protocol or gui).
If you're a bzr impaired developer, we have mirrors in GitHub (currently, only for the server, others will be added in the following weeks, ping us if you want any of these to happen sooner).
In any case, you may want to follow the Magicicada twitter account, where will be posting all kind of progress notifications.
