Why can’t we be friends?

During GUADEC, I took the time to do a little exercise.

Most times, I don't really pay any attention to trolls, let alone doing something to convince them that they are wrong. However, in the recent years there has been a rumour around that in the context of GNOME, there has been a growing tension between Red Hat and Canonical employees.

In order to exemplify and nurture the healthy coexistence of two rival companies within a community that strives for a symmetric and balanced treatment to all parties, I've been going around camera on hand to see how well Canonical and Red Hat employees like each other:

Unfortunately, things got out of hand, and the experiment only had limited success, here are a few subjects exposing inappropriate behaviour:

These last incidents have already been reported to the pertinent authorities.

Jokes aside, it is an immense pleasure to work with such an amazing community, full of remarkable people, employed or volunteers, you all rock guys.

On embracing the web

HTML is not the Holy Grail

There were a few talks at GUADEC that were around the topic of web and trying to figure out ways to build bridges to the web world from the GNOME community and technologies.

It was praised by some, most notably Luis Villa, that HTML/CSS/JS was the way to go. However I think that this is grabbing the stick from the wrong end in many ways.

The interesting parts of the web are not its front end technologies as such (the fact that they are standards and you can assume everybody has a browser is though). The interesting bit of the Web as a platform is the ability to syndicate, publish and aggregate content.

I actually think that the so called fact that people love HTML+CSS+JS is sort of a myth. The reason there's so many people doing stuff with it is not because it is a great technology, it's because:

  • You can reach a huge user base deploying a web app
  • It has a lean learning curve

People go through the pain of building apps with these technologies because it's worth the pain, and actually, for a lot of applications it's the better option. But it's still a pain.

However, suggesting that this is how GNOME should move ahead is in my opinion not the fastest path to provide a great user experience. Which is what GNOME is all about.

It's all about the data!

In my opinion, what we really fail at is at providing tools to create rich user experiences for data driven applications, and ways to feed data from the web more specifically. This has a lot to do with the poorness of our platform when it comes to ways to talk HTTP, libsoup for example is not such a great API for application developers for many reasons.

Then there's Gtk+'s lack of proper views for large datasets and GtkTreeModel is not necessarily a general purpose data model API. This is why, by the way, we developed libmodel at Codethink and created a GtkTreeModel wrapper around it.

I think the ones really pioneering in this field are the Intel guys with libsocialweb and Adrien Bustany on online providers for Tracker. But we still miss the "glue" for our great front end technologies (Gtk+/Clutter/MX) so that application developers can put together apps consuming and pushing online data real quick.

The browser is nice and all but…

There is a reason why Google, one of the main pushers of the web
technologies, still have Java based apps in the android platform. There is a reason flash is not going away and Silverlight and JavaFx are here to stay as well. The
closer you are to the hardware, the better the user experience can be. The quicker you can put together your apps, the better.

Pushing the boundaries of HTML is a nice thing and I'm happy to see Flash, Silverlight and JavaFx going away as substitutes of content that could be deployed as web content in the first place, but innovation and design by committee are not real good friends. We need a platform that can move as quick as hardware does, as much as we need a web platform as well that can cherry pick the innovations

Opportunities for collaboration, our friends from Mozilla

G3428

There is however a huge opportunity for the GNOME community, if we start making steps towards a better toolchain for data driven applications, I think building bridges with the Mozilla community can be a major win. I know what you're thinking, Gecko. No, I actually think WebKit is the way to go as our rendering engine, Gecko is there to follow Firefox's agenda. Fair enough.

There's a space in which building bridges with the Mozilla community can be even a biggest win for both ends, the web services space. Mozilla is creating amazing web services and tools, Firefox Sync, Bespin, Contacts.

GNOME seriously lacks of a community of people dedicated to build web services around the platform, and Mozilla is has that sort of focus. Together I think we can join forces solve this ongoing problem of closed source web services and all the privacy concerns around them by building a truly rich and open ecosystem of server and client side technologies.

A year of codethoughts

Last Friday I made one year at Codethink Ltd, and it's been a really fun ride so far, currently I'm actually quite happy with the company and the value I'm adding to it. A few months ago I got promoted from project manager to member of the board of directors which is both a scary and exciting.

Manchester is a great city, looking back I can't think of a better move for me both professionally and personally, plus working in a small company is been a totally different kettle of fish compared to Sun Oracle.

Img_01421-277x300 
Img_01681-300x225  

The best part is the people, we have an amazing team and we have the luxury to make substantial contributions to quite a few open source projects.

Company wise, things are going quite alright, not that I can comment much on our current plans but if things go as expected you'll hear some interesting stuff from us soon. By the way, if you are looking for support and top expertise on the GNOME and Freedesktop stack, we are available for contracting! Drop me a line to alberto.ruizcodethink.co.uk if you're interested.

Some pending browser breakthroughs

Loads of stuff going on recently on the <video> tag land, Google has made a bold move to push openness into the web, though they added Adobe into the mix, which inspires mixed feelings on me. All in all good news, competition is back on track after 10 years of Microsoft stagnancy on this field. I wish there was more corporations whose business model wasn't based on restricting competition through twisted uses of Copyright, Intellectual Property and business practices.

However, I would like to enumerate a few things that should be exposed or improved in the major browsers soon if they want to accelerate the web application further.

Webcam Access

I think this is actually the last thing we need to get rid of flash at this point and it's relatively straightforward to implement. I don't even think that a standard should be proposed for this to implement it. There's a lot of engine specific stuff on CSS and is not a big pain, most people are relying on jQuery and other cross browser libraries. The only challenge here is the security model, but Flash solved that long ago.

RDF Storage

When I saw a proposal to use SQL as one of the storage models for the browser something died inside me. I understand where the proposal is coming from and why it seems to make sense. Most web developers are familiar with SQL.

I think SQL is sort of alright on the server side as you can always expose data any way you want, but client side, you'll end up with a bunch of data silos for every site and you'll lose a lot of data in the way. A RDF/SPARQL model is the natural storage model for the web, though in my opinion some specific purpose APIs should be added for contacts, location and multimedia storage.

Obviously I'm a bit biased here since Codethink is been the major pusher for an RDF datastore on GNOME through our involvement in the Tracker project.

Smart Card Certification

Smart Cards are becoming widely used, in some countries like Spain the official ID card is an actual Smart Card with a digital certificate that can be used to sign documents (no biometric crap or anything like the crappy Labour proposal in the UK).
However this can be sort of configured already in some browsers, the setup is rather hard. Some projects like Tractis.com could really use some improvements in the ease of use.

Contact Support

I believe the Mozilla guys are already working on this area, what I would actually love to see is a tag where you can specify a contact detail like this:

<contact href="phone://004400000"/>

Same for skype, Facebook, XMPP, etc. plus a javascript API to access the phone features such as phone call, add an entry to the addressbook, send sms… Maybe RDFa instead of a new tag would do it as well. The point is that there should be a common way to define a contact on the document so that the client can do smarter things with it.

These are the main things I would add, although I would like to see a more widespread support for location support and touch based events as wells, I think the three items listed about could actually bring a significant amount of useful and innovative apps both online and offline.

Introducing BuilDj: Software Project Definition Format that GNOME deserves

In the GNOME beer event, I had a nice chat with ebassi about the problems around our build configuration system and how things like CMake, SCons and Waf do not get the full picture and do not cover some of the really strange corncercases that autotools supports and therefore, coming up with a solution would be a 1 year work with a team of really experienced engineers.

As stubborn as I am, I decided to prove him wrong so I give you BuilDj:

The Problem

My main problem with our current Autotools situation are these:

  • It is not portable as it encourages strong use of Bash and command line tools which ends up making it really hard to use on a non POSIX system, you know, like that used by 92% of the desktop users, even if the source code itself is perfectly portable.
  • It gets on your way, a lot. Sometimes I refrained from writing some testcases just to avoid to add the Autotools boilerplate.
  • Really bad documented, still.
  • You need to learn M4/Autoconf, Automake, Make and Bash to use it properly, as if learning C, C++ or Vala and worrying about the problem the programmer is trying to solve is not hard enough.
  • None extends it because it's hard to extend.
  • Its hard to read and understand even if you eventually wrote it yourself, makes code refactoring a big pain.
  • You simply can't parse autotools and have an IDE or a continous integration tool to understand what's there.
  • The most important one, it scares peoples away, damaging our mindshare, making potential contributors go away. It drains the fun out of our platform.

Requirements

We need a human+machine friendly project description format, that it's pleasant to the eye when you read it, that it's intuitive enough to let you understand what's going on even if you never saw it before.
A format that gets out of your way!

It should support all of the common tasks a GNOME maintainer does (in-line .pc and .desktop file definition, mkenums, gobject introspection support, cross-compilation support, pkg-config oriented, xdg mimetype registration/definition, integration with intltool), but it should suppor them in a meaningful and unobtrusive way.

It should not be a programming language, but support embedable programming extensions with a well documented API, so that IDEs can integrate it.

My Proposal

 A JSON description format called BuilDj that is build-system agnostic (although its reference implementation is done with Waf)

{
"project":
{
"name": "BuilDj Test",
"version": "0.0.1",
"url": "http://www.codethink.co.uk"
},
"requires":
{
"gtk+-2.0":
{
"type": "package",
"version": "2.14",
"mandatory": "True"
}
},
"targets":
{
"my_shared_lib":
{
"type": "sharedlib",
"tool": "cc",
"input": ["lib.c"],
"version": "1.2.3"
},
"my_gtk_program":
{
"type": "program",
"tool": "cc",
"input": ["gtk_program.c"],
"uses": ["my_shared_lib"],
"packages": ["gtk+-2.0"]
},
"my_vala_program":
{
"type": "program",
"tool": "vala",
"input": ["vala_program.vala"],
"packages": ["gtk+-2.0"]
}
}

I don't even need to explain what that means right? By the way, this stuff already works, check the git repository.

Currently it is implemented as a waf wscript that parses the project.js json file, I'm not really interested in entering the build system wars but focuing on having a reference implementation of the format.
I choosed waf because it was the only one that offered most of the features I want as an approachable API and it only adds python as a dependency.

Implementations of the format in other systems are more than welcome, but current development will stick to waf in the foreseeable future.

I'm planning to propose and mentor this work as a Summer of Code project so that we can implement the missing basic features and support for a few GNOME apps.

There's a lot of work to do, support for C++, library and function checking, system type sizes, full cross compilation support. We already have some mockups and plans for those, and the waf maintainer has shown himself quite happy to accept patches upstream for the general purpose tools and that make things easier.

Despite the missing features, it surprisingly itches some of my own scratches already.

P.S. Anjuta and MonoDevelop guys, if you're listening, I'd love to get your feedback!

Gtk+ Kick Start Tutorial for Vala

There are many problems with the way we present development documentation to users in the GNOME platform. The content is all pretty much there already, however it's quite fragmented and it lacks proper format and organization.

To address this a while ago I tried to put together some screencasts to promote the platform better and provide official documentation that is not focused on explaining every single piece of API or that is not focused to C developers.

After almost a year of trying to find the right combination of stable screencasting/video editting applications and spare time, I've finally put together the first of what I expect to be a series of screencasts targetted to promote the GNOME development platform in a useful way.

Gnome TV - GTK+ Kick-Start Tutorial for Vala
OGG

Any feedback would be welcome, but note that putting this together has been quite a difficult task. Hopefully there will be more of them now that I've managed to put together a nice timeline. Suggestions and help would be appreciated.

PS: I would like to give kudos to the PiTiVi guys, the app is no perfect, but it allowed me to perform the task which is something that no other video editor within the official Ubuntu repositories could say.

Contact Synchronization: Ovi.com vs. Google

I'm the kind of person that loses his items quite easily (wallet, keys…), those who are like me know pretty well that having a backup of the phone contacts is something essential. A year ago I lost my phone and by the time I was just using the Addressbook app in Mac OS X as it was the only software piece I could get to sync with my phone by Bluetooth, however, that event ended up with me writing a python script to translate a CSV file into something the Nokia PC Suite could understand to shove it into my new phone.

Since then I've been looking for a more universal way, and now that data access through 3G is moderately affordable, I've been having a look at online services for doing this instead of USB/Bluetooth methods. My main requirements were that I could backup and sync within several phones, a web UI to manage the contacts and a public API that allowed 3rd party integration.

Ovi Contacts

Ovi.com is Nokia's online integrated service, they offer maps, music store, calendar, pictures… and of course contacts sync. Since my two phones are Nokia I reckon I would give this a try. Setting it up was a piece of cake, you register your phone model+number and they send you an SMS with the configuration settings ready to be loaded in your phone, after that, you just have to the synchronization option in the connectivity menu and you're phone would upload all your contacts to Ovi.

The Good

  • The Web interface is quite neat (though contact navigation could use some AJAX love)
  • The setup was really smooth and the steps to follow are pretty straightforward plus the web interface to manage your contacts is not too bad.
  • Standard compliant (Ovi accounts are XMPP, sync is done through SyncML)

The Bad

  • The lack of publicly available SDK or documented API
  • SyncML is the only public way to access it from a 3rd party app
  • SyncML endpoint settings are not documented (found them in a forum entry)

The Ugly

  • Only supports Nokia phones which is a big show stopper

Google Sync

Google Contacts is a neat hidden feature of your Google account in addition to Google Sync allows the synchronization and management of your personal addressbook. They have setup instructions for a wide range of phones models. However with non android phones you have to set the syncml endpoint manually which is kind of a showstopper to non tech savvy people.

The Good

  • Setup documented for a wide variety of phone models from many vendors.
  • Google Data API with many SDKs for different platforms
  • Standard compliant (Google accounts are XMPP, sync is done through SyncML)
  • Matches Google Talk/XMPP custom aliases with phone contacts (someone's avatar showed up in my phone out of the blue. neat!)

The Bad

  • The contact database can easily be mixed with your automatically added gmail contacts which can be quite messy over time.
  • No SMS setup, SyncML settings have to be inserted manually.

The Ugly

  • Web interface sucks, managing your contacts is a pain in the arse.
  • Google knows enough about us already? 🙂

Conclusions

Eventhough Ovi was keeping me happier in general terms the first time I tried it, the lack of documentation and support for developers and non Nokia phones is kind of a show stopper in general terms. I'm not suggesting they should support every service on phone in the world, but supporting some of the basic services the best selling ones (iPhone, Android, Blackberries…) would be a huge win to gain mindshare around the service.

As for Google Contacts/Sync, the fact that it's already supported by many apps and phones around is a big point for it, the web interface and it trying to be too smart at matching your google talk/gmail contacts with your phone contacts is a bit annoying some times but still nice.

I'm gonna use Google Sync for now as I don't want to be stuck with Nokia in case a switch phones in the future.