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.)
how can you technically achieve to have the main application and his fork not to diverge too much so that code exchange can actually happen?
That is the challenge. Not every change to one will be desireable for the other. However, the elementary crew seem disciplined enough to merge small commits to satisfy particular fixes, and the commits we want for Shotwell we hope will apply easily enough.
rage-tag on: This really pisses me off. It is always the same: Once a piece of ‘linux’-software tends in the direction to be useable for non-hackers it becomes boring for developers, gets forked and finely messed up. What about fixing bugs instead of forking and introducing new buggy features?
Ohh, for sure, I totally forgot, FLOSS is all about freedom, choice and stuff. Quality, reliability and usability aren’t listed. So, why to care about …
Indeed, 2014 becomes the year of THE linux desktop.
You’re making a lot of assumptions. No one here is bored with Shotwell, and I’m indeed lending a hand as much as I can to assist elementary. I also don’t recall anyone at elementary talking about glittery new features as much as cleaning up and improving the experience.
I have been following the development of Shotwell for a few years and I use it *a lot*, it’s an awesome piece of software.
From time to time I checked the status of face recognition, it seems there is some work . I even compiled Shotwell with faces support but the UI lacked some features like autocompletion or contacts’ integration.
There is some news or short term plans to integrate faces into the main tree? Can I expect to have a usable face recognition soon?
Thanks and good job!
I can’t promise any short term changes to the situation. This is something elementary might be interested in tackling. The features you mention lacking were a big part of the reason we didn’t land the branch in master.
Jim,
Sorry for the off-topic. I’ve been watching Yorba for several years now and I’m really interested to work for you, albeit remotely, from Europe. I’m mostly a C++ guy, but getting hands dirty in Vala sounds really exciting 🙂
Is there any chance you could consider a remote candidate from Europe?
Thank you,
Zura
Alas, we’re not hiring right now.