May 2013

Freeing Feeds: From Paid App to Open Source

Check out Feeds on Github, or Download it from the website.

About a year ago, I created Feeds to scratch an itch. I wanted a desktop app that would help me keep tabs on our team’s commits to Github. Designer Eric Grossnickle wanted a way to see his Dribbble activity without having to check the website every day.

So, we built a little app that lives in your Mac menubar and notifies you when things happen on your favorite sites. It provides your notification history, read/unread status, and popover content previews.


In building Feeds, we wanted something that other non-developers could use to stay up to date not only with Github, but also with other services people depend on like the CRM tool Highrise or the collaboration app Trello.

Thanks to Eric, Feeds is beautiful. It’s easy to use and supports a decent set of third-party sites, as well as supporting RSS/ATOM feeds directly.


But I think we can do better. In order to support more services and keep the existing ones up to date, we need the support of other developers who personally use Feeds.

So we decided that the best way to expand the services Feeds supports is to open it up to the community. Starting today, Feeds is now free for direct download from the official website.

The App Store version will be removed (existing customers will continue to receive support), and the code is now available on Github so that anyone can contribute fixes and add support for new services.

So how did we end up here?

Keep it Simple (for the user)

When we conceived of Feeds, what we didn’t want was a full-fledged “RSS Reader.” There were some other RSS+Menubar type apps out there but they were a bit…much.


We thought we could make a notification app that was simple enough for non-geeks to use. Copying and pasting RSS feed URLs was not simple enough. It’s also been the trend for web software like Trello to move away from RSS feeds entirely, so we needed to support proprietary APIs in some cases.

So we decided to treat each service separately and support it directly. I created a “plugin” system where each service has its own Objective-C Account subclass. This was more work for us, but much less work for the user. Want to add your Basecamp account? No need to click around on the site looking for an RSS link. Just enter your username and password and that’s it.


That’s it, Huh?

Yeah, not so much. I think we achieved our goal of making a simple and intuitive UI for Feeds, but it turns out that creating and maintaining support for a dozen different web services is exactly as much work as it sounds like.

Since launch, my work on Feeds has been very much a side-project, and as the only programmer, things have moved more slowly than I’d like.

What’s worse is that my personal motivation to work on Feeds often depends on the services I’m using myself at any given time. For instance, I used to monitor our customer deployments on Basecamp every day at work, but now that we have a dedicated team working on that, I haven’t been there in months.

Similarly, we’ve replaced Trello with Asana at my workplace. So although Feeds still supports both Basecamp and Trello, I know that if I were using it every day myself, our support might be a lot better.

The Mac App Store


When we first launched Feeds, we decided to distribute it exclusively via the Mac App Store, pricing it at a spendy $4.99, since it targets a fairly niche audience.

The App Store has been an insanely great way to publish software in a way that other people can discover and pay for it easily. Full stop. It’s amazing. But it is not without its downsides. (Bet you didn’t see that coming!)

One unique challenge to the App Store that we all know and love is the fact that every app and every app update must be reviewed by a human. This can take some time.


Feeds, unlike most apps, is at the mercy of services that are completely outside our control. When a popular service like Github or Dribbble changes their website or API in a way that breaks Feeds, it may take us only a few minutes to produce a fix. But it has taken up to four weeks in some cases to get that fix through the App Store review team and into the hands of customers.

Four weeks is basically an eternity in the minds of our users, and I don’t disagree with them. They paid for a product and they expect it to work, and they write to our support email address and Twitter account telling us as much.

Because we want to provide great customer service, what we’ve done in these cases is create a special “test build” of Feeds containing the fix and distribute that to anyone we know about who’s experiencing the problem. This is a lot of work but it does keep folks happy.

There has to be a better distribution method for Feeds. And I believe that is opening it up.

The Path Forward

Before I embarked on the journey of making Feeds, I did a good amount of research looking for similar apps I could use instead of building my own. I found BaseApp, which was a lovely menubar app for tracking activity on Basecamp specifically, by the creators of the amazing CloudApp.


BaseApp was beautiful, BaseApp was functional, and BaseApp is now dead. I’m guessing because the authors no longer use Basecamp themselves.

I don’t want Feeds to end its life neglected as abandonware. I still think the concept is sound and simple. But it’s going to take a village.

For Feeds to survive, it needs care and feeding by the community of folks who enjoy it. If you’ve always wanted Feeds to support your favorite service, get in there and write a plugin. If you don’t know Objective-C, well, now’s a great time to learn. Just think, you’ll finally be able to execute on your brilliant iPhone app idea!

And if you haven’t tried Feeds yet, go download it for free and enjoy.

Notes (From Tumblr)

  1. nfarina posted this