Ubuntu One is not a “proprietary” service
Ever since Canonical started with Ubuntu One (or “U1″), people have been crying and whining about it being a proprietary pile of goo. For someone who has been active in the free software world for a long time, and still has his brains about him, this makes no sense whatsoever.
Yes, it is true that Canonical has not given up the source code for the U1 server-side software. And if you stop right there and proceed no further down the train of thought, you will probably come to the conclusion that it is proprietary software—and you would be wrong. Why?
Because the U1 client is free software, that’s why! It seems to me that we have forgotten what client/server applications are. Remember that HTTP is a client/server application, as is SSH, as are so many other types of things. It doesn’t matter if both sides have source code available, when it comes to client-server stuff. In fact, it almost doesn’t matter if the server side is available, because by itself it is useless. However, if the client source code is available, that tells you a great deal: it says, “here is how to talk to the server, how to communicate with the server, and how to use the server’s facilities in code that is useful,” and from that you can create an interface. Once you understand the interface, you need only to write software that fulfills that interface, and voilà, you have yourself a free software server that satisfies the client’s needs.
Then all you have to do is point the client to the new server software, installed somewhere on a server that you control, and you are all set. For that matter, I am somewhat surprised that nobody has done this just yet, because it seems to me that this would be a most excellent means to doing synchronization on systems in an office/workgroup setting. You could then set the Ubuntu One client to point to a server of your choosing and tell it, “sync all of the ~ directory” or “Sync all of ~/Documents” or whatever on every machine and you would have the ability to share and so forth… overall it seems like a great idea to me. Too bad I don’t have enough time to write it currently, though; I have a full plate of other projects (both in the realm of computing and not) that I have to get done first.
Unless, that is, someone wants to offer me some serious cash to write an U1 server implementation. Cash always advances a project to the head of the queue…
Sanders 18th June 2010
I’m surprised too that there is no U1 software replacement.
However what you do here is sort of throwing a stone and hiding your hand.
Developing client-server apps its never easy, and you need to take into account that having the source code is only half of the equation. One needs to get familiar with it, and keep shooting to a moving target as the original software maker keeps adding stuff to their server implementation.
I would make the case for Canonical releasing the server side too, so people like I, who will never ever pay for anything online that I can make myself for free on my own server, can use it, and at least trust it so to recommend other people (willing to pay for the service) to use the service.
In the mean time, I’ll stick to rsync + ssh.
Michael Trausch 18th June 2010
I’m not sure that I follow.
If all that were published were just a Doxygen-style API documentation for an access library, then yes, it might be more difficult than it needs to be. However, that’s not the case; we have a fully free software (GPLv3 even) client that we can use to test against a server. Anyone who can read Python (and that’s a *lot* of people) can read the code that goes into the U1 client and write a specification based on the code, even doing something like writing it in the style of an RFC so that it can be made easy to implement. Take, for example, the HTTP standard which can be easily turned into code for either a client or a server because it’s written decently.
It should also be possible to read the client code and create a skeleton server implementation that is stubbed out and just needs to be filled in, where it returns errors for things that aren’t implemented. As I mentioned in my post itself, I have not had the time to do it, though if I *did* have the time to do it, I likely would be working on it already. It would be nice, as I could use a solution for storing close to a terabyte of synchronized data using the type of technology that is built into U1. Alas, near real-time synchronization of that data isn’t a high priority at this time, and weekly rsyncs will have to suffice.