Category Archives: Yorba

GNOME, Yorba

Recent GNOME work you might be interested in

9 Comments

Jim Nelson - CC BY-SA 3.0

Yorba recently received funding from Adam Dingle toward fixing a smorgasbord of bugs in the GNOME ecosphere — from gedit to Epiphany to Nautilus to GTK, and more.  The quantity of tickets (over fifty!) and the breadth of the applications they covered meant we needed to find someone with a particular affinity for the depths of GTK and GObject.  Fortunately, we found such a person in Garrett Regier, who’s been doing a smash-up job the past few weeks knocking down these particularly aggravating bugs.

To give a taste of some of the fine work Garrett’s been up to:

As you can see, most of these so far are annoyances, but long-standing annoyances that can make the user feel there’s something not quite right.  Some were down-right maddening.  Consider the over-enthusiastic file chooser bug.  As time went on, its reporter “trained” himself to work around it.

Garrett is still at work on Adam’s list and so more fixes should be dropping soon.  In addition, we’ve asked Garrett to start working on larger projects, including a Find in All Files gedit plugin that should be more stable and easier to use than the currently existing alternatives.  Stay tuned!

 

Geary, Yorba

Geary crowdfunding: What went wrong?

62 Comments

OMG! Ubuntu ran a postmortem yesterday: Why Did Geary’s Fundraiser Fail?  It’s a question we’ve been asking ourselves at Yorba, obviously.  Quite a number of people have certainly stepped forward to offer their opinions, in forums and comment boards and social media and via email.  OMG!’s article is the first attempt I’ve encountered at a complete list of theories.

Although I didn’t singlehandedly craft and execute the entire Geary crowdfunding campaign, I organized it and held its hand over those thirty days.  Ultimately I take responsibility for the end result.  That’s why I’d like to respond to OMG’s theories as well as offer a few of my own.

Some preliminary throat-clearing

Let me state a few things before I tackle the various theories.

First, it’s important to understand that the Geary campaign was a kind of experiment.  We wanted to know if crowdfunding was a potential route for sustaining open-source development.  We weren’t campaigining to create a new application; Geary exists today and has been under development for two years now.  Unlike OpenShot and VLC, we weren’t porting Geary to Windows or the Mac, we wanted to improve the Linux experience.  And we had no plans on using the raised money as capital to later sell a product or service, which is the usual route for most crowdfunded projects.  Our pitch was simply this: donate money so we can make Geary on Linux even better than it is today.

Also, we didn’t go into this campaign thinking Yorba “deserved” the money.  We weren’t asking for the community to reward us for what we’ve done.  We were asking the community to help fund the things we wanted to develop and share.

Nor did we think that everyone in the FOSS world needed to come to our aid.  Certainly we would’ve appreciated that, but our goal was to entice current and prospective Geary users to open their wallets and donate.

I hope you keep that in mind as I go through OMG!’s list of theories.

OMG’s possible reasons

“$100,000 was too much”

This was by far the most voiced complaint about the campaign.  It was also the most frustrating because of its inexact nature — too much compared to what?  When asked to elucidate, I either never heard back from the commenter or got the hand-wavey response “It’s just too much for an email client.”

It’s important to point out — and we tried! — that Yorba was not asking you for $100,000, we were asking the community for a lot of small donations.  Your email account is your padlock on the Internet.  Just about every online account you hold is keyed to it.  It’s also the primary way people and companies will communicate with you on the Internet.  Is a great email experience — a program you will use every day, often hours every day — worth $10, $25, $50?

Another point I tried to make: How much did it cost to produce Thunderbird?  Ten thousand, fifteen thousand dollars?  According to Ohloh, Thunderbird cost $18 million to develop.  Even if that’s off by a factor of ten (and I’m not sure it is) we were asking for far less.  (Incidentally, Ohloh puts Geary’s current development cost at $380,000.  I can attest that’s not far off the mark.)  Writing a kickin’ video game, a Facebook clone, or an email client takes developer time, and that’s what costs money, whether the software is dazzling, breathtaking, revolutionary, disruptive, or merely quietly useful in your daily routine.

The last Humble Indie Bundle earned $2.65 million in two weeks.  Linux users regularly contribute 25% of the Humble Haul.  Is that too much for a few games?  Not at all.

“The Proposition Wasn’t Unique”

I agree, there are a lot of email client options for Linux.  What I don’t see are any that look, feel, or interact quite like Geary, and that’s one reason Yorba started this project.

We were in a bind on this matter.  We wanted the Geary campaign to be upbeat, positive, and hopeful.  We saw no need to tear down other projects by name.  We preferred to talk about what Geary offers and what it could grow into rather than point-by-point deficiencies in other email clients.  (Just my generic mention in the video of Geary organizing by conversations rather than “who-replied-to-whom” threading was criticized.)

That there are so many email clients for Linux does not necessarily mean the email problem is “solved”.  It may be that none of them have hit on the right combination of features and usability.  That jibes with the positive reaction we’ve received from many Geary users.

“People Consider it an elementary App”

I honestly don’t recall anyone saying this.  If this notion stopped anyone from contributing, it’s news to me.

To clarify a couple of points: OMG! states there are a few elementary-specific features in Geary.  That’s not true.  The cog wheel is not elementary’s.  We planned that feature before writing the first line of code.  Geary once had a smidgen of conditionally-compiled code specific to elementary, but it was ripped out before 0.3 shipped.

elementary has been a fantastic partner to work with and they supported Yorba throughout the campaign.  Still, Yorba’s mission is to make applications available to as many free desktop users as possible, and that’s true for Geary as well.

“They Chose the Wrong Platform”

Why did we go with Indiegogo over Kickstarter?  We had a few reasons.

A number of non-U.S. users told us that Paypal was the most widely-available manner of making international payments.  Kickstarter uses Amazon Payments in the United States and a third-party system in the United Kingdom.  We have a lot of users in continental Europe and elsewhere, and we didn’t want to make donating inconvenient for them.

Unlike Indiegogo, Kickstarter vets all projects, rejecting 25% of their applications.  And one criteria for Kickstarter is that a project must be creating something new.  We’re not doing that.  One key point we tried to stress was that Geary was built and available today.  (We even released a major update in the middle of the campaign.)  There is no guarantee they would’ve accepted our campaign.

Another point about Kickstarter: a common complaint was that we should’ve done a flexible funding campaign (that is, we take whatever money is donated) rather than the fixed funding model we elected to run, where we must meet a goal in a time period to receive anything.  Kickstarter only allows fixed funding.  A few people said we should’ve done a flexible funding campaign and then said we should’ve used Kickstarter.  It doesn’t work that way.

“Not Enough Press”

I agree with OMG!, we received ample press, but more would not have hurt.  The Tech Crunch article was a blessing, but what we really needed was more coverage from the Ubuntu-specific press.  Even if that happened, I don’t feel it would’ve bridged the gap we needed to cross to reach the $100,000 mark.

A couple OMG! missed

There are two more categories that go unmentioned in the OMG! article:

“You Should Improve Thunderbird / Evolution / (my favorite email app)”

We considered this before launching Geary.  What steered us away from this approach was our criteria for conversations over threading, fast search, and a lightweight UI and backend.

Thunderbird is 1.1 million lines of code.  It was still under development when we started Geary.  We attended a UDS meeting where the Thunderbird developers were asked point-blank about making its interface more like Gmail’s (that is, organizing by conversations rather than threads).  The suggestion was flatly rebuffed: use an extension.  For us, that’s an unsatisfying answer.

Evolution is 900,000 lines of code, and includes many features we did not want to take on.  Its fifteen years of development also bring with it what Federico Mena Quintero succinctly calls “technical debt”.

(Even if you quibble with Ohloh’s line-counting methodology, I think everyone can agree Evolution and Thunderbird are Big, Big Projects.)

In both cases, we would want to make serious changes to them.  We would also want to rip features out in order to simplify the interface and the implementation.  Most projects will flatly deny those kinds of patches.

In comparison, Geary stands at 30,000 lines of code today.

“I Use Web Mail.  No One Uses a Desktop Client Anymore”

Web mail is convenient and serves a real need.  Web mail is also, with all but the rarest exceptions, closed source.

Think of it this way: you probably don’t like the idea of installing Internet Explorer on your Linux box.  If you do, you probably would at least like to have an open-source alternative.  (Heck, even Windows users want a choice.)  Web mail locks you out of alternatives.  People are screaming about Gmail’s new compose window.  What can they do about it?  Today they can temporarily disable it.  Some time soon, even that won’t be available.

Consider the astonishingly casual way Google has end-of-lifed Google Reader.  Come July 31st, Google Reader is dust.  I don’t predict Gmail is going away any time soon — it’s too profitable — but every Gmail user should at least have a fallback plan.  And if Gmail did go away, Google would take with it all that code.  (This is why Digg, Feedly, and others are rushing to create Google Reader lookalikes rather than forking what exists today.)  Not so with open-source email clients.  That’s why asking Yorba to improve Thunderbird or Evolution is even askable.  Yorba improving Gmail?  Impossible.

That’s the pragmatic advantage of open-source over closed: code never disappears.  Even if you change your email provider, you’re not stuck relying on your new provider’s software solution, if they even have one.

The principled advantage of free software is that you’re supporting open development for applications that don’t carry riders, waivers, or provisos restricting your use of it.

My theory

That’s the bulk of the criticism we received over the course of the campaign.  However, I don’t think any or all get to the heart of what went wrong.  Jorge Castro echoes my thinking:

Lesson learned here? People don’t like their current email clients but not so much that they’re willing to pay for a new one.

All I’d add is that over one thousand people were willing to donate a collective sum of $50,000 for a new email client.  Let’s say Jorge is half-right.

I don’t intend this post to be argumentative, merely a chance to air my perspective.

Next time I’ll talk about the lessons we learned and offer advice for anyone interested in crowdfunding their open-source project.

Announcements, Geary, Yorba

Geary crowdfunding: What’s next?

47 Comments

geary-yorbaThirty days comes and goes faster than you think.  The Geary crowdfunding campaign’s 30 days are up, and unfortunately, we didn’t make our target amount.  That means Yorba will take in none of the $50,860 pledged by 1,192 generous donors over the past month, who will receive refunds.

I’d like to thank each person who pledged to the Geary campaign.  That money represented more than dollars and pennies, it represented trust in Yorba and the work we’re doing to bring high-quality software to the Free Desktop.  $50,860 is not small potatoes, and 1,192 donors in 30 days tells me we’re doing something right.  Even if we “failed” I like to believe we succeeded in some sense.

What’s next?  In some ways, it’s back to business for Yorba.  We’re still coding.  In fact, we released new versions of Geary and Shotwell (even Valencia!) during the crowdfunding campaign, which has to be some kind of record.  We’re working now to find other sources of income to cover our costs.  All options are being considered.

That said, please consider giving directly to Yorba.  If you pledged and are going to receive a Paypal refund, you can still donate some or all of that money to Yorba knowing it will be put to good use.  Every dollar we take in is a little more oxygen for Yorba to continue developing free software.  Just follow this link to donate:

http://www.yorba.org/about/donate/

Thanks everyone!

Geary, Yorba

Geary crowdfunding: how did we come up with that number?

18 Comments

geary-yorbaThe Geary crowdfunding campaign has been a wild three days so far!  We’ve even been featured in a TechCrunch article, “Crowdfunding, Micro-patronage, And The Free Desktop”.  Scott Merrill had some tough questions for me about how the money we raised would be used.  Others have also commented elsewhere about our target of US$100,000.  Are we asking for too much?  Why do we need that kind of money?

Plainly put, software development is expensive.  You can do it in your spare time, but it’s exactly that — your spare time, the odd moments in your life when you choose to put other obligations aside and devote yourself to the intricacies of code.  The success stories are out there.  Many are the stuff of computing lore, but you never hear of the multitude of abandoned weekend projects.  Coding in fits and bursts is a strategy of mixed results.

Yorba has three full-time engineers working on Geary.  We’re not going to use the raised money for sparkling new development systems or personalized catering.  Yorba’s major equipment and infrastructure purchases have already been made with past income.  The crowdfunding contributions we take in go toward people hacking on Geary code.

“An email client isn’t worth $100K,” one commenter complained.  I doubt there’s a widely-used desktop application out there developed for less than US$100,000 — it’s just that the price tag might be hidden from its users.  The person coding in their spare time is working for free, but that doesn’t mean their spare time is worthless.  Perhaps your favorite app was developed thanks to corporate sponsorship and is distributed freely.  But with that subsidy comes a price tag in terms of priorites, direction, maintenance, and, as the Google Reader announcement last week reminds us, potential abandonment.  “Great software is worth paying for.”

Yorba has no corporate sponsorship.  That strategy has worked for some open-source projects, and I’m not knocking it out-of-hand.  But direct contributions from our users means we can place their priorities — your priorities — first.

Other software crowdfunding campaigns have asked for less than US$100,000, so why is Yorba asking for so much?  Games are a good example of “cheap” crowdfunding.  They raise money by selling pre-release copies as part of their perks or incentives (“For $50, you’ll get a signed copy of the game”) and then selling full-price copies when the game is completed.  Other software campaigns develop online subscription services and offer perks of free subscriptions — again, a model of pre-selling the software in order to raise money to develop it.

This is all fine, but that’s not the position we’re in.  Geary is free software: you will forever be able to download and build Geary on your own.  Heck, you can download and run it today.  We’re not pre-selling software nor are we building an email service.  In fact, we want Geary to work with all kinds of email systems, not lock you into ours.  We want to take what we’ve started and make it better — no, we want to make it great.

Finally, remember that we’re not asking you for US$100,000.  Rather, we’re asking for everyone to contribute a little toward that amount.  What’s a program like Geary worth to you?  Most people leave their email open all day long.  They’re constantly working with it: reading a conversation, marking an email as a “to-do” for later, replying to one request, then sending off a note to someone else.  We want Geary to make all those tasks a snap, so easy you’re not even thinking about Geary, but rather the email in front of you.

What’s that worth to you?  $10, $25, $100?  That’s the question we’re posing with our crowdfunding campaign.  Please considering contributing today.

Announcements, Geary, Yorba

Geary funding campaign is live on IndieGoGo! Donate today

3 Comments

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, GNOME, Shotwell, Yorba

Stirring the pond

Leave a comment

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.