Category Archives: Geary

Geary funding campaign is live on IndieGoGo! Donate today

geary-192x192A couple of weeks ago, I told you we were working on a crowdfunding project for Geary:

We hope that a successful campaign will demonstrate that crowdfunding is a sustainable model for other projects to follow. Many of those projects have historically relied upon corporate sponsorship. Crowdfunding brings with it an independence that these other revenue models lack. It allows us to continue to operate independently and build the features you, the community, really want to see.

Well, that day has arrived.  Our IndieGoGo project is now live and ready to accept your donations!  Please take a look and consider contributing.  We need your donations to continue working on Geary and making a great application you can use day-to-day for all your email needs.

Here’s a nifty video we put together explaining what we’re trying to do:

We need to spread the word and get out the news.  Please share the campaign with your friends on Facebook, Twitter, Google+, and your favorite open-source forums.  And if you see mention of the campaign on news sites, please upvote or share it — every little bit really does help.

Thank you for supporting us.  We can’t do this without you!

Geary 0.3 released

We at Yorba are pleased to announce the release of Geary 0.3, our lightweight email client.  Geary organizes your email by conversations rather than threads and offers full HTML composition, attachments, and more.  Geary is compatible with Gmail, Yahoo! Mail, and most IMAP servers.

This major release brings many significant improvements and changes, including:

  • Support for multiple accounts
  • Account editor
  • Basic full conversations
  • Some lightweight background downloading of messages
  • Mark as spam/not spam
  • “Important” folder support
  • Multiple compressed messages are collapsed in conversation viewer
  • Mark as read as you scroll in conversation viewer
  • Highlight unread messages in conversation viewer
  • Allow auth-less SMTP
  • Conversation viewer WebKit inspector
  • Many, many bugfixes

The Geary 0.3 tarball is available for download.  See Yorba’s wiki for information on building, running, and contributing to Geary.  Report bugs and feature requests at Yorba’s Redmine server.  (You must create an account before adding or modifying tickets there.)

Ubuntu users can also find a version for Quantal Quetzal (12.10) on Yorba’s PPA.  Adventurous users may also wish to subscribe to Yorba’s Daily PPA.

Exciting times for Yorba (we need your videos!)

Yesterday was an auspicious day here at Yorba: Shotwell is four years old.  It’s hard to believe that from that rather meager first commit grew the photo manager we have today!

Well, today is another auspicious day here at Yorba.  Some of you may remember that last year at GUADEC 2012, Adam Dingle and I gave a keynote discussing how the open source community could attempt to find sustainability via crowdfunding.  I’m thrilled to share that we’re ready to put some weight behind that idea: Yorba plans in the near future to begin such a campaign for our newest application, Geary, a lightweight modern email client for the GNOME desktop. Our hope is that a successful crowdfunding campaign could bring in sufficient revenue to make Geary a world-class email application.

We hope that a successful campaign will demonstrate that crowdfunding is a sustainable model for other projects to follow. Many of those projects have historically relied upon corporate sponsorship. Crowdfunding brings with it an independence that these other revenue models lack. It allows us to continue to operate independently and build the features you, the community, really want to see.

One key element to all crowdfunding campaigns is a short video that describes the vision of the project. We plan on producing exactly that kind of video. We would love it if we could include testimonials from our users about the software experience Yorba has provided in the past. Please consider making a short video of yourself (under two minutes) describing your experience with Geary and/or Shotwell: what you like about them, why you use them, and more importantly, one or two of your top Geary wishlist items — features that would make it the perfect email client.

To submit your videos, email with a link to your video — FTP, YouTube, Vimeo, etc. — along with your name, your work or other affiliation (optional) and your location. We plan on starting this campaign soon, so we need your video testimonials by next Friday, March 15.

Wish us luck, and let us know your thoughts in the comments! We’d love to hear from you.

The Garden of the Forking Paths

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 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.

Stirring the pond

Copyright Robin Webster (CC BY-SA 2.0)

If you’ve ever submitted a ticket to Yorba, you probably received an email from our Redmine server some time in the last week or so.  I’ve been going through each Shotwell and Geary bug one-by-one in an attempt to circumscribe the rather large, rather muddy pond they’ve grown into.  Each alteration and classification I made triggered emails to the original reporter, the maintainers, commenters, and more.  Thanks for your patience with us.

When I first waded into the ticket pond, Shotwell had something like 980 tickets; Geary, 390.  (I didn’t take notes throughout this process so I don’t have exact figures.)  Today the Shotwell pond is down to 898 tickets; Geary, 363.  That’s a modest 8% reduction, and I haven’t finished the job.  Most of that reduction is from closing duplicate and invalid tickets.  Some were the result of making hard choices.

If you’re a maintainer of an open source project with a large and steadily growing ticket database, I’d like to share what I learned the hard way this week:

Your tickets describe a possible future.  When you leave a ticket open, you’re saying, “Yep, this is something we’d like to do.”  If you’re not planning to fulfill a ticket, close it.  One unneeded ticket just further pollutes an already muddy and large pond and makes more work for you.  A key question to ask yourself is, Does fulfilling this ticket fit into the future we see (or want) for our program?

Watch out for tickets you “kind of” or “might” want to do.  If you use weasel-words to describe your interest in a ticket, that’s a red flag.  Don’t open placeholder tickets either — do you want to do this or not?

Another important question is, If someone submitted a patch for this, would we land it?  You don’t want to open a ticket and then reject a patch someone spent their precious weekends putting together because — whoops! — you don’t want that ugly feature after all.

You might be lukewarm about a ticket and think, “Hey, if someone does the heavy lifting for us, we’ll land their code, no problem!”  Remember: if you take a patch, you’re taking responsibility for that code.  Code you’re “okay” with today could be a nightmare tomorrow, and users don’t like it when features vanish.

Be bold.  Wikipedia’s motto is one of the best pieces of advice given on the Internet, period.  You can’t please everyone, and what’s more, you won’t, so wield an axe when triaging tickets.  Jeff Atwood talks about not letting your users convince you to build a truck when you’re building a car — good advice, especially since they might actually want a car.  Ticket triage is a lot like emergency room triage: each patient is important, but when there’s 980 of them, you turn away the toothaches (which, if you think about it, shouldn’t be in an emergency room).  It’s tough to drop a ticket because there’s always that nagging feeling that maybe we should keep this around…  Remember there are ramifications for keeping a ticket open, as I mentioned already.  Be bold.

… but not too bold. One ticket I thought did not describe the right approach to a problem.  A little push-back from users and a little more digging on my part revealed I’d made a false assumption.  Being bold doesn’t mean not listening or skipping investigation.  Don’t assume a bug’s gone away just because no one’s reported it in a while.  You can’t thoroughly test every case, but at least have some justification beyond inconvenience.

Look for jumping-off points into the pond.  Nine-hundred eighty tickets is a lot of tickets to slog through.  I decided to break down the Shotwell tickets into categories to open up some alternate ways to divvy up the problem.  To date I’ve only categorized about half of the tickets, but even that much was worth it.

The first obstacle I faced was defining “category”.  My first inclination was to think of subsystems as categories.  Soon I realized that associating a bazillion tickets by code location doesn’t really give you the perspective you need.  I decided to concieve of our apps as solving various tasks (“workflow”) and categorize that direction.  For Shotwell (a digital photo manager) I created categories like “camera” (i.e. hardware interaction), “raw”, “import”, “metadata”, “editing”, and so forth.  (If this was the 90s, I’m sure “printing” would’ve made the list.  Today it’s “web-sharing”.)  Not only did this help my immediate problem, it’s also more intuitive for the user who has to pick one when reporting a problem — compare to a user facing such intutive choices as “async” and “cairo”.  I’m still shaking out the categories thing — but again I say, be bold.

All kinds of magic happens with good categories.  Duplicate tickets popped up like flowers in the snow.  Inter-related tickets (potentially solved at the same time) suddenly seemed obvious.  What’s more, obscured problem areas jump out.  Our users are complaining about Shotwell’s duplicate detection (which prevents importing identical files) at various points in the application.  Each ticket was a nit and a theory about the best way to work around it.  Stepping back from them as a whole, I realized these tickets described a broader problem that we should solve as a whole, not in piece-parts.  If we hacked through the tickets one-by-one, we would’ve added a lot of workarounds and unrelated features, creating code complexity and an inconsistent user experience.

One word: Need Information.  A number of the tickets’ comment trails ended with asking the reporter for more information and never hearing back.  Some of these queries were years old, and without that information we legitimately couldn’t move forward to fix the problem.  These tickets I marked as “Need Information” and added a brief comment asking if the reporter could get back to us.  Thanks to email notification some of them did respond, even years after the fact.  Like not leaving open tickets you don’t plan on fixing, no reason to leave tickets open you legitimately can’t fix.  I plan on reviewing the remaining Need Information tickets a few months from now.  If they’re still blocked or unanswered, it may mean it’s time to close.

Stir the pond every so often.  It took a chunk of time, but I feel like we now have a better grasp of the problems we’re really facing, which means getting the changes our users want to them sooner.  This whole exercise took time, but I’m glad I did it.  What’s more, I think it’s something that should happen at regular intervals — every six months, maybe once a year.  Stirring through all the tickets is a good way to sift through the water a bit and see what’s lurking beneath the surface.

Announcing Geary 0.2.2

We’re pleased to announce the release of Geary 0.2.2, Yorba’s lightweight email client. Geary organizes your email by conversations rather than threads and offers full HTML composition, attachments, and more. Geary is compatible with Gmail, Yahoo! Mail, and most IMAP servers.

Improvements for this release include:

  • PLAIN authentication fixed on Yahoo! and other SMTP servers
  • geary.desktop file always built and installed

The Geary 0.2.2 tarball is available for download.

See Yorba’s wiki for information on building, running, and contributing to Geary.

Report bugs and feature requests at Yorba’s Redmine server. (You must create an account before adding or modifying tickets there.)

Ubuntu users can also find a version for Precise Pangolin (12.04) on Yorba’s PPA.

Adventurous Ubuntu users may also wish to subscribe to Yorba’s Daily PPA.