Tag Archives: ubuntu

Announcements, GNOME, Shotwell

Shotwell, elementary, and Pantheon Photos: What it all means

8 Comments

Last Friday Daniel Foré made an announcement on elementary’s mailing list that has generated a considerable amount of interest:

Shotwell needs a new maintainer. … After some discussion with Jim, we think the best course of action is for elementary to fork Shotwell.

OMG! Ubuntu reported later that day (and with surprising speed) that “Elementary To Take Over Shotwell Development”.  I’ve received emails from people wondering what this means for the future of Shotwell.

To be clear, Yorba remains the maintainer of Shotwell.  elementary has not taken it over.  Yorba recently took the rather large step of moving Shotwell and all its associated work (including our ticket database, wiki pages, architecture guidelines, and more) into the GNOME infrastructure. We didn’t do all that work just to hand the keys over to another group on another platform.  We made the move because, when we did all the calculus, we agreed GNOME was the best location for the future of Shotwell.  Going into the GNOME infrastructure opened (and is still opening) a lot of doors for us.  However, Yorba’s resources are limited, and as of late we’ve not been focused full-time on improving Shotwell.

This put us into a bind, and so I began looking for outside individuals or groups who would be capable and willing of contributing to Shotwell in a more substantial way.  I kept coming back to a group that has shown a great deal of energy and motivation in the past and a willingness to work with us: elementary.  They expressed a lot of interest in improving Shotwell, and so we began a discussion about how that situation might look.  In the end, we reached an understanding:

  • Shotwell will continue to be maintained by Yorba.  We’ll triage bugs, take patches, fix critical bugs, ensure it builds with the latest versions of Vala and supporting libraries, and runs on the major distros.  Yorba will continue to release Shotwell on a six-month schedule.
  • elementary agreed to jump in and improve Shotwell, but stated that all of their development must occur on Launchpad.  They also wanted to rebrand the project to fit under their design umbrella.  This includes integration with Contractor and other technologies they’re building for their OS.
  • It was agreed that they would fork the project to Launchpad and rename it Pantheon Photos to distinguish it from Shotwell.  The pragmatic reason for this is to prevent name collisions with packaging.  This also allows for elementary to customize Shotwell to their own platform and brand it separately.
  • As Shotwell maintainers, we’ll evaluate elementary’s work and look for commits that are useful to Shotwell users.  We’ll cherry-pick that work and merge it into the Shotwell base.
  • elementary agreed not to relicense Shotwell, so its current license (LGPL 2.1) stands.

While elementary has big plans for Pantheon Photos, none of that work is happening in private and we’re free to take improvements as we wish (and likewise they’re free to pull improvements from Shotwell’s code base).

Additionally, this situation already exists, and has existed for years, with Ubuntu: they maintain their own fork of Shotwell to provide integration with Ubuntu Online Accounts.  (I’ve referenced that situation before.)  elementary is doing this on a larger scale, admittedly, but it’s not unique in the world of open-source and shouldn’t be a source of alarm.

(I regret that Daniel wrote “Shotwell needs a new maintainer.”  I was privy to that email before it was posted and should’ve asked he reword it.  That was my fault, not his.)

I can’t emphasize enough that Shotwell is not being discontinued or end-of-lifed, and elementary has not “taken over” Shotwell.  We’ll continue to maintain Shotwell and release versions with our usual distribution targets.  This is why I tweeted that this situation is a win for everyone (a sentiment echoed by Bryan Landuke) — users won’t necessarily have to pick-and-choose which app they want to use, or even which distribution, in order to manage their photos.
Announcements, Geary

Would you like to see Geary 0.4 available on Ubuntu 12.04 / elementary Luna?

7 Comments

geary-yorbaWe’ve received a lot of complaints from users that Geary 0.4 isn’t available for Ubuntu 12.04 (Precise Pangolin) and elementary Luna.  It wasn’t an arbitrary decision on our part.  As we developed Geary 0.4, we learned that more and more components that Geary relied on were changing or simply unavailable in 12.04/Luna.  There’s a tangible engineering cost to maintaining backward compatibility.  At some point this summer we realized it was too much work to maintain support for 12.04/Luna as well as newer versions of Ubuntu, Fedora, and all the other distros out there.

But Ubuntu 12.04 and elementary Luna (which is based off of 12.04) has a steady fan base who would really like to run Geary 0.4.  What to do?

We have limited resources, but we don’t want to leave users out in the cold.  We believe this is a problem both Yorba and the community can solve.  So we’ve created a bounty for the problem — if someone out there (or a group of people) solves this problem for us (and therefore everyone else!), they’re rewarded with cold, hard cash.  It’s that simple.

If you’re interested, read on:

There’s two pages you should read: the issue ticket at Yorba’s project server (which details the problem and the stipulations for collecting the bounty) as well as the bounty page at Bountysource.com (where the promised funds are listed).

If you want to see Geary 0.4 work on 12.04/Luna, you can help.  Go to the bounty page at Bountysource.com and pledge what you can.  The more the community offers, the more motivation developers have to take on this challenge.  It’s not easy what we’re asking for — whomever takes this on deserves a reward for their time, energy, and expertise.  What’s more, if no one solves this problem, you get your money back (minus Bountysource.com’s fee).

If you have the right stuff to backport Geary 0.4 to 12.04/Luna, dive right in.  Make sure you read the issue ticket first for all the stipulations.  This isn’t a simple matter of getting Geary to compile on 12.04.  You have to make sure anyone running 12.04 can install it via their package manager.  Yorba’s developers are willing to guide you along, offer advice, point out resources or commits that you might be interested in.  But you need to make it happen.

Just to show that we’re serious about this, Yorba has already pledged $500 toward this bounty.  We’re hoping the community will toss in more money to further sweeten the pot.  If everyone who has asked us to backport Geary 0.4 to 12.04/Luna offered $10, $25, or $50 toward the job, there would be no problem finding someone to do the work.

(Note: Yorba employees are prohibited from collecting any bounty money for Yorba-related projects.)

Geary, GNOME, Hacking, Shotwell

The Garden of the Forking Paths

22 Comments

A thought experiment:

A software developer decides to write an open-source GNOME desktop application that interacts with any number of Internet services, such as Facebook, Gmail, Flickr, and so forth.  It’s not specific to any one service, however.  The app should take advantage of all the available desktop technologies, not only to leverage all that hard work, but also to be a good desktop citizen.

The first thing the application does is log in to an Internet service.  What should this developer do?

(a) Handroll the authentication code.  Most Internet services use a token-exchange system, but each service is different, so the developer will need to write custom code for all of them.  The user will want the application to save the password for next time, so better look into keyring solutions.  And there’s always the problem of where and how to store long-term tokens, since every service has its own Terms of Agreement.  And don’t forget to request Application Keys — each service has its own.  Some services have different entry points for their various “faces” (i.e. Yahoo! and Flickr) while some have a federated login system (i.e. Google).

Halfway through the process the developer thinks, “Why am I reinventing this wheel?  A lot of applications could use this code.”

Or (b) Use a system library.  The developer calls the library and gets back a token.  No messing around with passwords, keyrings, confirmation Web pages … all that’s handled by the system service.

The developer thinks, “Perfect!  Problem solved and we’re being a good desktop citizen because the user only has to enter their password once.”

(b) seems the obvious choice, right?

Then the developer learns that Ubuntu and most of its derivatives (Ubunten?) use Ubuntu Online Accounts (UOA).  The rest use GNOME Online Accounts (GOA).  UOA and GOA are not API/ABI compatible.

Suddenly (a) looks like an appealing prospect.

This is a poisonous situation for application developers.  It’s not terribly visionary of me to suggest that the number of programs that interact with Internet services — the magical “cloud” — is only going to grow over time.  GNOME and Ubuntu are both acutely interested in attracting more developers (or at least should be).  But new and curious developers arrive and are confronted with this situation.

I speak from experience.  Both Shotwell and Geary could use some kind of Online Account solution today.  Canonical has forked Shotwell to call UOA rather than our handrolled code, but those patches have not migrated upstream, nor could we take them as-is.  Requiring UOA would preclude Shotwell from running on non-Ubunten distros.

I’m not here to argue UOA vs. GOA, or GNOME Shell vs. Unity, or lament that there’s yet-another split on the desktop.  I accept that both sides have decided to go their own ways (here’s Debarshi Ray giving his reasons).  But we at Yorba want Shotwell and Geary to work well — no, work spectacularly — on all GNOME desktops.  That we can’t deal fluidly with something as low-level as server credentials seems absurd.

I once had a professor tell me, “All problems in computer science are solved with a layer of indirection.”  He was being snarky, but there’s a germ of wisdom in that observation.  It seems to me that the solution to the GOA/UOA divide could be solved with a translation or wrapper library.  I’m not thrilled about wrapper code, but sometimes that’s what you’ve got to use.

To throw the first dart at the dartboard, here’s my proposed interface for such a library:

  • Enumerate supported Internet services: Facebook, Yahoo!, Google, etc.
  • Query a particular service for details/capabilities/description/icon/etc.
  • Generate an authentication token for a particular service
  • Launch the login/account registration application (i.e. the GOA/UOA program that takes the user though the steps of logging in to a service and making it available to all applications)

Obviously it’s far more complicated than this, but that’s the gist.  I know GOA is DBus-based, and I believe UOA is as well, so the solution could simply be a DBus interface that both technologies implement, perhaps in the org.freedesktop namespace.  In fact, maybe this should be a freedesktop.org initiative.

We need something.  Asking an application developer (including Yorba) to pick UOA or GOA is a non-starter.  There seems to be a bit of bad blood between the GOA and UOA camps — I don’t know all the details — but I ask both of you to scratch together a bridge rather than fork the path.

Yorba

Yorba in Copenhagen

1 Comment

Earlier this month, several of us Yorbans made a trek to Copenhagen for Ubuntu Developer Summit (UDS.) It’s a beautiful city with lots to see. For the most part the weather behaved well and we were able to wander around and see the sites, albeit bundled up in three layers of jackets.

Here’s some photos we took in Copenhagen and at UDS.