Giving up maintainership of libgdata

libgdata is a GObject-based wrapper for Google’s APIs, providing desktop bindings for Google Calendar, Drive/Documents, Tasks and YouTube APIs.

I’ve maintained it since 2009, and I no longer have the time/energy/bandwidth to do so. I’m standing down as maintainer.

This leaves libgdata in not such a great position. In order to be usable in the future, it needs to be ported to libsoup3, a process which has begun (and which quite a bit of energy has been put into), but which has not been completed. I don’t have any energy to complete that process, so libgdata still currently uses libsoup2.4, a library which is going away soon.

Given that Google services are important on the desktop for a number of people (mostly those using Google’s business groupware suite), the functionality which libgdata currently provides needs to continue.

I see two options here:

  1. Someone takes over maintainership of libgdata, completes the libsoup3 port, and maintains it as a stable library with documentation, tests, API stability, etc. This means more work on libgdata, but a lot less work for the users of libgdata to continue using it.
  2. libgdata is abandoned and split up, and the code in it which is still useful is moved into the projects which use it. This would be less work on the libgdata side, but more unrequested work for the projects which use it. They’d have to integrate a load of shipwrecked code from libgdata and finish porting and re-testing it against libsoup3.

Option 1 would be less painful in the short term, but option 2 would perhaps be better in the long term. libgdata is old, written in C, and I’ve been finding that its strict C API guarantees aren’t a good match for Google’s cowboy style of rewriting and replacing web APIs every couple of years. The cadences just don’t match, which leads to busywork being needed in libgdata to port it to each new version of the Google web APIs while maintaining the same C API. Splitting it up and removing a lot of the API guarantees would make it easier to support new web API versions and features without so much bureaucracy.

Option 2 would also allow for the GData binding code to be ported away from C, if users of it wanted, which would be good for security (as it does parse untrusted data from the network).

So this post is a request for the people/projects who use libgdata to decide amongst themselves which course of action would work best for them, and work out how to resource it.

I’m not going to do a handover period or anything like that which could become drawn out and protracted. After posting this message I’m going to remove my maintainer bits for the project. The release team can give out new maintainer bits, or move the project to the archive, based on what people decide.


Thanks for maintaining libgdata for so long, Philip!

afaik the port to libsoup3 is complete? Any idea what is missing?

Review and testing. Most of the code changes there are straightforward, but there are some more complicated ones to do with threading. The MR rewrites the download and upload code, which is not trivial and is uniquely placed to be able to corrupt a user’s Drive files in two directions. It’s not something to YOLO merge.

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.