On the technology behind UbuntuOne: iFolder, mono and all that jazz…

Well… keeping myself to the technical side of things. I know the following about UbuntuOne:

  • It is one week ago I heard about it for the first time after blogging about iFolder, weird eh?
  • I found the O’reilly UbuntuOne link after googling Ubuntu One. Comments on blog posts rock!
  • A lot of people have been ranting about it, and others just discussing it
  • Too many blogposts, bugs and mailing list threads about it for me to link to any of them. I am actually kind of done with that discussion. Business is business! Freedom is freedom!
  • The client side seems to be free software and based in mono  (since it seems to use the iFolder client code base, although this might be wrong as this mono assumption is based on a comment on my blog.
  • I like the idea of having iFolder or part of it at least in Ubuntu as I have expressed in previous entries since I dream of dropping that box in my own server or servers, since simias, the iFolder server side, actually might even support p2p tech now

So now, let’s wait and see how people start using the mono argument against UbuntuOne (even if it ends up being wrong)… People have too much time available for ranting.

Meanwhile those interested or involved on the technology behind UbuntuOne (client and cloud) please drop a comment and let us all know more. I want to know it all. Thanks in advance! 🙂

And yes, I got an invite. Yes, I have signed up for the service. Yes, it rocks! Yes, I still want my own server to do the same (or similar) thing.

~ by huayra on 2009 May 15.

17 Responses to “On the technology behind UbuntuOne: iFolder, mono and all that jazz…”

  1. AFAIK UbuntuOne is Python-based, not Mono

  2. Well, part of the problem is exactly that UbuntuOne is not open source, so you would need to: expect that Canonical begins to sell self-hosted versions of UbuntuOne, do some reverse engineering, do the same using other aproach, or wait for it to be open sourced… I don’t know what will be faster.

    • Alberto, Please stop spreading stupid lies, the client is *completely free software* AND the protocol is *completely free softare*. The *only* piece that is closed is the server backend that runs on Canonical’s servers. Because the protocol is open, anyone is free to write their own server piece, and release it as free software. There is literally nothing stopping this, and I’m sure the community would love it.

      Also, Ruben, as Jo said the client is all python.

      • OK, but you don’t have to be that rude, dude!

        Python rulez! 🙂

        The problem here is that iFolder is the only option and it is mono based. A lot of people are going to react to the fact of having mono on their servers.

        But again I am proposing this for Universe, not Main, so…

  3. Yes, the client is written in python and is new software (you can see the source yourself at http://bazaar.launchpad.net/~ubuntuone-control-tower/ubuntuone-client/trunk/files )

  4. Is this post about UbuntuOne or Mono ? I’m starting to think that Mono blinds.

    Please correct this post. If you lack infos on UbuntuOne check my blog, google more and better or drop to #ubuntuone and care to ask.

    Ps: I don’t see canonical developing Mono products any time soon.

  5. The reality is…if the UbuntuOne service is popular…and
    if Canonical is committed to keeping the clients open and the wire protocols documented..it will be possible to reverse engineer the server side. Ifolder would be a logical place for that work to happen…if it happens. Maybe even something like the open source version of DimDim will gain support for the UbuntuOne service protocols once UbuntuOne adds collaboration services and competes more directly with DimDim’s web service model.

    The UbuntuOne service itself isn’t a ground breaking issue, its just one more closed web service. The really difficult question is, will the Ubuntu community come to a consensus as a community to support the free software ideals of The Franklin Street Statement?
    Certainly Canonical won’t be a strong backer of The Franklin Street Statement as its a direct challenge to Canonical’s business model.

    Your own personal interest in finding a replacement of DropBox may be an anecdotal evidence of a growing appreciation of the ideals set forth in The Franklin Street Statement. You aren’t alone, Ubuntu as a community is not alone. The wider FOSS community is behind the curve on this issue and it looks like things are just starting to get re-organized into a coherent advocacy push to free SaaS and network services. The people behind indenti.ca and libre.fm should be given a lot of credit for being among a group of pioneering group to build truly open web services. Can Canonical be persuaded to change course and follow thier lead? I don’t know. It would take a prolonged advocacy campaign inside the Ubuntu community itself, and its not clear to me that the Ubuntu community has the stomach to take Canonical on over this issue.

    Though its a funny thought isn’t it? Ubuntu advocates seem to do such a good job of spreading Ubuntu externally bringing more people into contact with FOSS ideals..but the most important advocacy challenge may not be their friends and neighbours in the brick and mortar world..the important challenge maybe Canonical’s own web services based business culture.

    A portion of the Ubuntu community will undoubtedly join that effort. But in doing so they will come into direct conflict with Canonical’s business interests. And that’s the real long term problem. Canonical’s long standing closed web services business interests maybe divergent with the larger Ubuntu community’s evolving stance about SaaS freedoms. How will Canonical and the Ubuntu governance structures deal with that advocacy as it grows internally in the community? The issue isn’t going to go away, if anything this will become a thorny issue as web services become more vital to day-to-day usage habits.

    • This are exactly the questions and issues I am trying to address in this post.

      This really is just an experiment. And yes I am making a controversial statement just in order to get this discussion rolling from a different perspective.

      Now, if iFolder is the only viable option and it is all mono, what do we do? Is mono a trap, as Java used to be?

      So, if we were to create a Free Software compatible server side based in iFolder, some people would start arguing about the use of mono, even if its purpose is to actually give a real FLOSS alternative to closed and propietary “cloud” solutions. Think beyond UbuntuOne: Box.net, DropBox and the like… They are all the same really in this context.

      My post is trying to raise awareness about the importance of a free cloud, of the AGPL, of Free Software being everywhere without traps of any kind.

      I am not discussing the trademark issue, and I do not have a problem with Canonical experimenting with several products and business models. I am not the person to try to stop anyone, what I care about is Software Freedom!

      To finalize: Do we have a cloud option that is viable in the Free Software world? I do not know of any option besides iFolder… And it is all mono, mono, mono!

      Which, I personally, don’t mind.

  6. Do you plan to correct your article, publish my comment and perhaps think again and better or what ?

    Spreading this kind of crap just hurts Mono.

  7. “Java”.

  8. […] already has it as well, not to mention Debian Sid.”Someone wrote about Novell’s iFolder and Mono in relation to UbuntuOne, stating wrongly that “The […]

    • It’s not about Ubuntu One being mono, it’s about the only alternative to Ubuntu One, or any similar cloud service, being mono based: iFolder.

      This whole thing was started by a comment done by Jef in my previous post about iFolder that mentioned Ubuntu One being mono based.

      It was wrong, but at the time almost nobody knew anything about Ubuntu One, and still it does not change my point.

      This post is a critic and a social experiment as I stated above.

  9. I don’t want to enter into a blog war (specially about this issue, which is going to divide the Ubuntu Community).

    But the fact is the server *is* closed, so If you want a self hosted solution, the three options ( a) A self hosted solution provided by Canonical, b) Reverse engineering of the server code to implement it yourself or c) Wait if Canonical open source the code as It did with Launchpad) apply fully.


    • As loong as there are options and no closed source software enters my default install I am cool with it.

      If Canonical wants to offer this service and people do not mind what license its software runs, it’s ok with me.

      I use gmail and other google services, so I am not complaining… What I am stating here is that there’s an option, iFolder, and that option is based in mono. I do not mind since mono is FLOSS, but other people probably will because of the Novell deal with Microsoft about cooperation, the weird license given to moonlight and the like.

      So my conclusion: the most the Ubuntu community talks about iFolder, the most likely it is that someone will package it for Ubuntu.

      My goal is to get that done and thus resolve this bug: https://bugs.launchpad.net/ubuntu/+bug/87122

      Then I can happily choose to use iFolder or not, while other people go around discussing the mono issue and making blog wars about this and that. I am not one of them


  10. as we’ve seen in the gnote/tomboy flamefest something written originally is not necessarily difficult to port to another language.

    And a correction I never say UbuntuOne was written in mono. I said that Ifolder will most likely be important part of the larger UbuntuOne portfolio of services. You’ll note that Canonical is already looking at adapting F-spot(written in mono) to support UbuntuOne..its a sprint topic at UDS. Mono as a barrier to adoption is quite low. Nothing really competes with F-spot as a GNOME desktop application currently.

    If the Ubuntu One storage protocol is actually useful iFolder will most likely gain support for it..though Canonical might not be the one doing that integration work as it might not benefit them in the short term to have an open service implementation walking around.

    If people are unwilling to use iFolder or F-spot due to mono, then someone will port them to another language. All of this work is just a matter of time and desire. How long was tomboy around before someone rewrote it in C as gnote? Several years.

    I give it about a year before we start to see alternative back-end UbuntuOne service offerings like iFolder integration being available for wide use. That may happen sooner if Canonical pushes desktop client support for the storage protocal into the upstream GNOME desktop as new core feature in such a way that desktop users can select which service provider to use. Once there is a widely available service provider agnostic client configuration, there will be more interest in developing different server backends which leverage the storage protocal.

    If I were you I’d also watch to see how the Conduit project reacts to the existance of UbuntuOne. Conduit may gain support as an alternative client interface to the U1 storage protocal.

    The storage protocal is actually far more interesting than the backend service code itself. It would be a real win if the different service providers like Dropbox, Spideroak and Jungledisk worked with Canonical to support a standard, extensible network API for storage services. The U1 storage protocal could be that sort of API..but Canonical would need to champion it as a Freedesktop specification and start the conversation with GNOME and KDE to drive support of the API into core elements of the desktop frameworks. The open/closed service backends and open/closed application support would then each develop independently at a natural pace based on conformance with the standard protocal.


  11. […] shed light on this from a technical/juridical point of view? I might be wrong, you know… As I’ve been […]

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

%d bloggers like this: